RE: Ada OS talk (was: Progress on AdaOS)

RE: Ada OS talk (was: Progress on AdaOS)

[Robert C. Leif, Ph.D.]

From: Bob Leif
To: M. A. Alves et al.

I totally agree with, "To that effect I propose a generic principle of
simplicity/smallness.  That is why my messages have a general "downsizing"
tone."
However, I suspect that Ada will permit both "simplicity/smallness" and
advanced functionality. If a file type is described as a generic private
tagged type in the kernel, functionality can be added in the outer layers.
Since one of the goals is efficiency, I would try to avoid those class-wide
subprograms (methods) that require run-time dispatching.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org]On Behalf Of
Sent: Monday, September 03, 2001 1:13 PM
To: comp.lang.ada@ada.eu.org
Subject: Re: Ada OS talk (was: Progress on AdaOS)


> > > Anyway, it *would* be libraries implementing the types of files.
> >
> > Yes.  That is what I meant with "different levels".  I still think you
> > need a storage element level as a building block for the file types and
> > other elaborations.  And this would be the role of the kernel.
>
> Right. The hardware is going to enforce this. But I don't want to reveal
> a storage-element level as a building block for directories, for
> example.

You are thinking Unix again ;-)  Dont!  Down with directories!  That is
just a way of grouping files among many others, including file typing, and
so also built upon the storage-element level.

> > By serialization you mean a (do_first, do_next, end_error) sort of
thing?
>
> No, I mean flattening into something that has to be parsed.
> . . .

OK.  Them it is definitely an outer layer (w.r.t. the kernel).

> > I think the best building block is the (un)bounded array of storage
> > elements, which is more than this.  But of course I may be wrong.
>
> It's a good low-level building block, but it's not a good higher-level
> building block. I think records are good. I think the ability to insert
> and delete records is good. I think the ability to have at least one and
> maybe many ordered indicies on records is good.

I meant the best _low_level_ building block.  Then a middle level layer
would provide records etc. but this edifice needs bricks.

> > > No more than a lack of image types in a kernel means that images
aren't
> > > implemented in a coherent standard ways. FORTH simply has library
> > > routines to handle directories.
> >
> > My point exactly.
>
> I'm lost. I don't think we're really talking about image types here.
> . . .

The point was that _both_ directories and file types are similarly above
kernel level, without hindering coherency or performance.

Not important an issue really at this point.  Hmmm... what point?  I would
expect this talk would result in a sort of strategic plan for building an
OS as a hobby by Adaists.  To that effect I propose a generic principle of
simplicity/smallness.  That is why my messages have a general "downsizing"
tone.  Remember the fall of the AdaOS.

--
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Progress on AdaOS

[Darren New]

David Starner wrote:
> 
> On Fri, 31 Aug 2001 20:00:07 GMT, Darren New <dnew@san.rr.com> wrote:
> > Making a strict separation like that is exactly the kind of thing that
> > causes mental impedence mismatch. It's the same kind of reasoning that
> > says "let the language deal with processes, and save threading for a
> > library." :-)
> 
> It's also the same kind of reasoning that says "let the language deal with
> text, and save XML for a library." What should go into the OS or
> language, and what should be supplied seperately is debated fiercely, but
> something's are going to have to go out, and some in.

Right. As an aside, since XML is a serialization technique, I'd leave it
to the libraries implementing the data types.

Anyway, it *would* be libraries implementing the types of files. I'm
just suggesting that serialization isn't a necessary component of a
"file", any more than you need to explicitly load and store pages for
virtual memory in modern systems.

> > On the other hand, FORTH really *does* use *only* storage elements. That
> > means no directories and no files. Your disk really is an array of
> > storage elements. Directories are the responsibility of your code. Is
> > that really what you want in a kernel?
> 
> Not having directories in the kernel tends to mean that directories aren't
> implemented in any coherant standard way.

No more than a lack of image types in a kernel means that images aren't
implemented in a coherent standard ways. FORTH simply has library
routines to handle directories.

> There are coherant standard ways
> _that are followed consistently_ in how to store data to disk, without
> it being in the kernel.

I'm not sure what this is supposed to mean. 
 
> > And
> > thinking that knowing that the "type" of the data in the file is
> > image/gif is vital, but being willing to read the file to find out of
> > it's GIF87 or GIF89 is OK too doesn't make sense to me.
> 
> Because whether it's GIF87 or 89 is a mostly irrelevant fact, and there's
> zero chance of confusing the two once you know it's a GIF file. Some thing
> much more interesting is whether it's a picture of Robert Dewar or Tucker Taft,
> but that's something no one's talked about putting in the type.

Well, my basic point there was that if you're going to have "strongly
typed files", as suggested by the original web pages, then the ability
to treat an image file as raw bits is a bad thing. The suggestion is
that a files data type cannot change without a change in content, but
this is just wrong. Certainly I can change a file's type from raw text
to HTML on most modern systems (including the Mac) without changing the
content.
 
> > I think Ada is powerful enough to have such ideas integrated seemlessly.
> 
> See, Modula-3 did have such ideas seemlessly implemented. Which raises
> two points: one, it's evidence that there's no need to do it in the
> kernel, that it can be done in the language or libraries without kernel
> help.

Well, it depends on what ideas you mean, really.

> Second, where's Modula-3 today? (Last time I checked, with one
> maintained compiler, which is a hack on an old version of gcc, and a
> nearly dead newsgroup.) If this was so important why didn't it succeed,

I never said it was important. I simply said it might be a good idea to
think about it for an AdaOS. Personally, I don't know why someone would
think an AdaOS is important simply because it's written in Ada.

> or at least the ideas get put into languages that are used? ABC also
> had persistant variables; but when Guido von Rossum made Python with
> ABC in fond memory, he didn't include persistant variables.

I think that's generally because it's hard to do with modern operating
systems. But if you're rewriting the OS from scratch, why start with the
assumption "Nobody else has done this, so we shouldn't do it either."

Anyway, nuff said.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Ada OS talk (was: Progress on AdaOS)

[M. A. Alves]

> Anyway, it *would* be libraries implementing the types of files.

Yes.  That is what I meant with "different levels".  I still think you
need a storage element level as a building block for the file types and
other elaborations.  And this would be the role of the kernel.

> just suggesting that serialization isn't a necessary component of a
> "file", any more than you need to explicitly load and store pages for
> virtual memory in modern systems.

By serialization you mean a (do_first, do_next, end_error) sort of thing?
I think the best building block is the (un)bounded array of storage
elements, which is more than this.  But of course I may be wrong.

> > Not having directories in the kernel tends to mean that directories aren't
> > implemented in any coherant standard way.
>
> No more than a lack of image types in a kernel means that images aren't
> implemented in a coherent standard ways. FORTH simply has library
> routines to handle directories.

My point exactly.

> > Because whether it's GIF87 or 89 is a mostly irrelevant fact, and there's
> > zero chance of confusing the two once you know it's a GIF file. Some thing
> > much more interesting is whether it's a picture of Robert Dewar or Tucker Taft,
> > but that's something no one's talked about putting in the type.
>
> Well, my basic point there was that if you're going to have "strongly
> typed files", as suggested by the original web pages, then the ability
> to treat an image file as raw bits is a bad thing. The suggestion is
> that a files data type cannot change without a change in content, but
> this is just wrong. Certainly I can change a file's type from raw text
> to HTML on most modern systems (including the Mac) without changing the
> content.

This is all fine, but, again, not at all kernelian.

I am being extremely kernelist as a lesson learned (negatively) from AdaOS
history.  They did not concentrate on the kernel--and the project failed I
think because of this at least in part. The current discussion is
excelent, but is about things outside the kernel.  And to get a kernel
_done_ I think a it should be simple viz.  provide a simple structure viz.
the (un)bounded array of storage elements as a building block and then
when the thing is going we can implement directories, file types etc.

In short: give me a OS that only handles "raw bits" and I can build
everything upon that; furthermore, aim at such an OS and you will get it
done; aim at a full-featured-OS-language-like OS and you will not even get
it started.

--
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Ada OS talk (was: Progress on AdaOS)

[Darren New]

"M. A. Alves" wrote:
> 
> > Anyway, it *would* be libraries implementing the types of files.
> 
> Yes.  That is what I meant with "different levels".  I still think you
> need a storage element level as a building block for the file types and
> other elaborations.  And this would be the role of the kernel.

Right. The hardware is going to enforce this. But I don't want to reveal
a storage-element level as a building block for directories, for
example.

> > just suggesting that serialization isn't a necessary component of a
> > "file", any more than you need to explicitly load and store pages for
> > virtual memory in modern systems.
> 
> By serialization you mean a (do_first, do_next, end_error) sort of thing?

No, I mean flattening into something that has to be parsed. Serializing
a DOM tree involves creating XML. Serializing a directory tree is what
"tar" does. Nobody works with XML as a big text string. Everyone parses
it into some internal representation, works with the internal
representation, then pumps the XML back out. Nobody works with a
directory tree represented as a tar file. Everyone runs it thru untar,
gets the tree, then does operations on the files within. For example,
how would you make all the files in a tarball globally readable? Would
you (a) run thru the tar file fiddling bits in the headers, or would you
(b) untar it, use chmod -R, then tar it up again?

> I think the best building block is the (un)bounded array of storage
> elements, which is more than this.  But of course I may be wrong.

It's a good low-level building block, but it's not a good higher-level
building block. I think records are good. I think the ability to insert
and delete records is good. I think the ability to have at least one and
maybe many ordered indicies on records is good. 

> > No more than a lack of image types in a kernel means that images aren't
> > implemented in a coherent standard ways. FORTH simply has library
> > routines to handle directories.
> 
> My point exactly.

I'm lost. I don't think we're really talking about image types here.
We're talking about how you store something more complex than an array
of bytes. If your kernel only supports "array of bytes" as a data type,
then someone has to write code for every non-array-of-bytes to store it
in an array of bytes then pull it back in again. This is what streams
try to do, except that you have to deal with pointers and such yourself.
 
> This is all fine, but, again, not at all kernelian.

It depends. I'd expect mmap() is neither particularly more nor less
difficult to implement than read() and write(). That, plus the
appropriate libraries, should be close to enough, for the file system
I'm talking about.

Of course, having programs that don't die is even better.
 
> I am being extremely kernelist as a lesson learned (negatively) from AdaOS
> history.  They did not concentrate on the kernel--and the project failed I
> think because of this at least in part. The current discussion is
> excelent, but is about things outside the kernel.  And to get a kernel
> _done_ I think a it should be simple viz.  provide a simple structure viz.
> the (un)bounded array of storage elements as a building block and then
> when the thing is going we can implement directories, file types etc.

> In short: give me a OS that only handles "raw bits" and I can build
> everything upon that; furthermore, aim at such an OS and you will get it
> done; aim at a full-featured-OS-language-like OS and you will not even get
> it started.

I don't think it's a question of whether the kernel sees the files as
"raw bits" or not. It's a question of "what does a process look like"
and "how does a process access a file". If a process is something that
never needs to exit, and all access to files is done via something like
mmap(), then your kernel can dispense with "file system" altogether,
allocating the entire disk as one big swap file. I can't imagine it gets
much simpler than this. Then all you need to do to make things
convenient is to tweak the runtime to let you allocate specific storage
pools to specific areas of memory, etc.

Of course, the pointers in such a memory-mapped storage pool will *look*
like raw bits to the device reading and writing sectors of disk. The
point is that they'll still look like strongly-typed pointers to the Ada
program.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Ada OS talk (was: Progress on AdaOS)

[M. A. Alves]

> > > Anyway, it *would* be libraries implementing the types of files.
> >
> > Yes.  That is what I meant with "different levels".  I still think you
> > need a storage element level as a building block for the file types and
> > other elaborations.  And this would be the role of the kernel.
>
> Right. The hardware is going to enforce this. But I don't want to reveal
> a storage-element level as a building block for directories, for
> example.

You are thinking Unix again ;-)  Dont!  Down with directories!  That is
just a way of grouping files among many others, including file typing, and
so also built upon the storage-element level.

> > By serialization you mean a (do_first, do_next, end_error) sort of thing?
>
> No, I mean flattening into something that has to be parsed.
> . . .

OK.  Them it is definitely an outer layer (w.r.t. the kernel).

> > I think the best building block is the (un)bounded array of storage
> > elements, which is more than this.  But of course I may be wrong.
>
> It's a good low-level building block, but it's not a good higher-level
> building block. I think records are good. I think the ability to insert
> and delete records is good. I think the ability to have at least one and
> maybe many ordered indicies on records is good.

I meant the best _low_level_ building block.  Then a middle level layer
would provide records etc. but this edifice needs bricks.

> > > No more than a lack of image types in a kernel means that images aren't
> > > implemented in a coherent standard ways. FORTH simply has library
> > > routines to handle directories.
> >
> > My point exactly.
>
> I'm lost. I don't think we're really talking about image types here.
> . . .

The point was that _both_ directories and file types are similarly above
kernel level, without hindering coherency or performance.

Not important an issue really at this point.  Hmmm... what point?  I would
expect this talk would result in a sort of strategic plan for building an
OS as a hobby by Adaists.  To that effect I propose a generic principle of
simplicity/smallness.  That is why my messages have a general "downsizing"
tone.  Remember the fall of the AdaOS.

-- 
   ,
 M A R I O   data miner, LIACC, room 221   tel 351+226078830, ext 121
 A M A D O   Rua Campo Alegre, 823         fax 351+226003654
 A L V E S   P-4150 PORTO, Portugal        mob 351+939354002

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

Any OS can treat the file system as a whole separate issue. Any Ada OS would
probably want to be able to read NTFS, Unix files, MS-DOS files, etc. as
well as maybe supporting its own thing. The point is, that discussion can be
stalled off until there is first a working Kernel capable of running a file
system.

Make the project too big and it will just crumble from its own weight. Take
the file system ideas and put them in a folder marked "To be argued about
after some level of success is achieved." I'd say the same things about
network support, etc., except in so far as a Kernel will need to leave the
door open to work in a networked environment. Beyond leaving the door open,
no other design decisions need to be made at this time.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"M. A. Alves" <maa@liacc.up.pt> wrote in message
news:mailman.999544263.23337.comp.lang.ada@ada.eu.org...
>
> The point was that _both_ directories and file types are similarly above
> kernel level, without hindering coherency or performance.
>
> Not important an issue really at this point.  Hmmm... what point?  I would
> expect this talk would result in a sort of strategic plan for building an
> OS as a hobby by Adaists.  To that effect I propose a generic principle of
> simplicity/smallness.  That is why my messages have a general "downsizing"
> tone.  Remember the fall of the AdaOS.
>

Re: Ada OS talk (was: Progress on AdaOS)

[Gary Scott]

A look at OS/2's recent file system(s) changes would be in order.  It
supports treating multiple hard drives as a single large drive,
transparently, easy to set up and use.

Marin David Condic wrote:
> 
> Any OS can treat the file system as a whole separate issue. Any Ada OS would
> probably want to be able to read NTFS, Unix files, MS-DOS files, etc. as
> well as maybe supporting its own thing. The point is, that discussion can be
> stalled off until there is first a working Kernel capable of running a file
> system.
> 
> Make the project too big and it will just crumble from its own weight. Take
> the file system ideas and put them in a folder marked "To be argued about
> after some level of success is achieved." I'd say the same things about
> network support, etc., except in so far as a Kernel will need to leave the
> door open to work in a networked environment. Beyond leaving the door open,
> no other design decisions need to be made at this time.
> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
> 
> "M. A. Alves" <maa@liacc.up.pt> wrote in message
> news:mailman.999544263.23337.comp.lang.ada@ada.eu.org...
> >
> > The point was that _both_ directories and file types are similarly above
> > kernel level, without hindering coherency or performance.
> >
> > Not important an issue really at this point.  Hmmm... what point?  I would
> > expect this talk would result in a sort of strategic plan for building an
> > OS as a hobby by Adaists.  To that effect I propose a generic principle of
> > simplicity/smallness.  That is why my messages have a general "downsizing"
> > tone.  Remember the fall of the AdaOS.
> >

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

I don't know if DEC invented it or implemented it first or anything like
that, but the first time I saw that was with VMS. They had "disk striping"
which let you spread files or a database across several drives for faster
access and/or redundancy. Not really that new since a disk with multiple
independent heads is essentially the same problem & I think those were in
existence a long time ago. Its a useful technique.

I'd consider that to be outside of the "file system" as an "implementation
detail" peculiar to a specific kind of device. A RAID or JABOD would be just
one storage medium among many. (Should a file system support paper tape,
punch cards and similar devices?)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Gary Scott" <Gary.L.Scott@lmtas.lmco.com> wrote in message
news:3B94E65B.CDA2CAB7@lmtas.lmco.com...
> A look at OS/2's recent file system(s) changes would be in order.  It
> supports treating multiple hard drives as a single large drive,
> transparently, easy to set up and use.
>

Re: Ada OS talk (was: Progress on AdaOS)

[Gary Scott]

I thought VM and MVS had this long before DEC.

Marin David Condic wrote:
> 
> I don't know if DEC invented it or implemented it first or anything like
> that, but the first time I saw that was with VMS. They had "disk striping"
> which let you spread files or a database across several drives for faster
> access and/or redundancy. Not really that new since a disk with multiple
> independent heads is essentially the same problem & I think those were in
> existence a long time ago. Its a useful technique.
> 
> I'd consider that to be outside of the "file system" as an "implementation
> detail" peculiar to a specific kind of device. A RAID or JABOD would be just
> one storage medium among many. (Should a file system support paper tape,
> punch cards and similar devices?)
> 
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
> 
> "Gary Scott" <Gary.L.Scott@lmtas.lmco.com> wrote in message
> news:3B94E65B.CDA2CAB7@lmtas.lmco.com...
> > A look at OS/2's recent file system(s) changes would be in order.  It
> > supports treating multiple hard drives as a single large drive,
> > transparently, easy to set up and use.
> >

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

Could be. Like I said, it was just in VMS that I first saw it in a
production setting. The concept has got to go back to the invention of the
disk drive since it is basically just an optimization technique for picking
the next track to read/write.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Gary Scott" <Gary.L.Scott@lmtas.lmco.com> wrote in message
news:3B9540ED.7EF3C7B5@lmtas.lmco.com...
> I thought VM and MVS had this long before DEC.
>
> Marin David Condic wrote:
> >
> > I don't know if DEC invented it or implemented it first or anything like
> > that, but the first time I saw that was with VMS. They had "disk
striping"
> > which let you spread files or a database across several drives for
faster

Re: Ada OS talk (was: Progress on AdaOS)

[Darren New]

> Any OS can treat the file system as a whole separate issue.

Not really. My point was that it's possible to create an OS where the
concept of "file system" doesn't even exist. I'm not sure what your
"kernel" is going to do other than process scheduling and I/O. What did
you have in mind?

Take a look, for example, at the EROS operating system. It's a bit
radical, but there aren't really "files" as such in it, in the sense
that the entire disk is one giant swap file and files are simply
variables held by processes. You do IPC to a process that has access to
the data you want in order to get it. The data isn't just "there"
without a process to access it for you.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

Well, I don't know what you want to call an "Operating System" but there are
plenty of real time OS's that never deal with the concept of a "File"
because the hardware has no use for it. An OS can have a means of
bootstrapping itself into some flavor of memory and start executing without
there being a "File System" in any conventional sense. Hence I believe that
its possible to deal with lower-level execution issues & get something
capable of running a program and save any file system issues for a later
date. (Oh, you'd probably have to dummy some things up since typically a
program has got to reside *somewhere* - but if the OS has some rudimentary
monitor built into it to enable program loading from some collection of
sources, you could build something that worked, without having to deal with
a file system.)

I understand the notion of having no visible file system in the traditional
sense. "Disk" is just seen as a kind of extension to "Memory". I have no
objection to that sort of design - except possibly that it makes you
incompatible to some extent with the rest of the universe and may have some
limitations. (How are you going to get at Unix or Windows files on a network
if there is no visible file system - or some extension thereof? Ada has
facilities for handling "files" so there ought to be some kind of support
for that. Does it need to be "traditional"? Not necessarily - but it ought
to allow for the fact that you'll want to look at stuff that isn't built
under your own home-grown system.)

I kind of like a generalization that says "all that exists is 'storage' so
don't distinguish between an array in memory and a file on disk". However,
any practical OS is going to have to deal with the need to get real specific
about devices & hardware at points in time. For embedded things, this is
obvious: "I need this particular EEPROM or that specific I/O port..." But
even in general purpose computers, programmers will find a need to insist
that data reside in specific physical devices. As long as you can get there
from here, I'm happy.

One of the better ideas I've heard was to base any file system on URLs so
that the interface to the software is the same no matter what kind of data
or where it resides. That works nicely in conjunction with XML as the means
for handling any GUI development. However, I'm still convinced that those
sorts of issues can and should be stalled off until some small level of
working OS is actually built and running.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Darren New" <dnew@san.rr.com> wrote in message
news:3B950BAD.B23ECB43@san.rr.com...
> > Any OS can treat the file system as a whole separate issue.
>
> Not really. My point was that it's possible to create an OS where the
> concept of "file system" doesn't even exist. I'm not sure what your
> "kernel" is going to do other than process scheduling and I/O. What did
> you have in mind?
>
> Take a look, for example, at the EROS operating system. It's a bit
> radical, but there aren't really "files" as such in it, in the sense
> that the entire disk is one giant swap file and files are simply
> variables held by processes. You do IPC to a process that has access to
> the data you want in order to get it. The data isn't just "there"
> without a process to access it for you.
>
> --
> Darren New
> San Diego, CA, USA (PST). Cryptokeys on demand.

Re: Ada OS talk (was: Progress on AdaOS)

[Ole-Hjalmar Kristensen]

Darren New <dnew@san.rr.com> writes:

> > Any OS can treat the file system as a whole separate issue.
> 
> Not really. My point was that it's possible to create an OS where the
> concept of "file system" doesn't even exist. I'm not sure what your
> "kernel" is going to do other than process scheduling and I/O. What did
> you have in mind?
> 
> Take a look, for example, at the EROS operating system. It's a bit
> radical, but there aren't really "files" as such in it, in the sense
> that the entire disk is one giant swap file and files are simply
> variables held by processes. You do IPC to a process that has access to
> the data you want in order to get it. The data isn't just "there"
> without a process to access it for you.
> 
> -- 
> Darren New 
> San Diego, CA, USA (PST). Cryptokeys on demand.

Radical, yes, but not new. IBM has done that for ages.

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen

Re: Ada OS talk (was: Progress on AdaOS)

[David Starner]

On Tue, 4 Sep 2001 09:02:04 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> Any OS can treat the file system as a whole separate issue. Any Ada OS would
> probably want to be able to read NTFS, Unix files, MS-DOS files, etc. as
> well as maybe supporting its own thing. The point is, that discussion can be
> stalled off until there is first a working Kernel capable of running a file
> system.

But you don't want to fall into the trap of ignoring the file system.
File systems are key part of an style - a FAT style fs, a VFAT style
fs, a NTFS style fs, a Unix style fs, a Mac OS fs - all made their
mark on their systems, with permissions, valid file names and structure.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Ada OS talk (was: Progress on AdaOS)

[Brian Catlin]

"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9n3h11$9ic1@news.cis.okstate.edu...
> On Tue, 4 Sep 2001 09:02:04 -0400, Marin David Condic
<dont.bother.mcondic.auntie.spam@[> wrote:
> > Any OS can treat the file system as a whole separate issue. Any Ada OS would
> > probably want to be able to read NTFS, Unix files, MS-DOS files, etc. as
> > well as maybe supporting its own thing. The point is, that discussion can be
> > stalled off until there is first a working Kernel capable of running a file
> > system.
>
> But you don't want to fall into the trap of ignoring the file system.
> File systems are key part of an style - a FAT style fs, a VFAT style
> fs, a NTFS style fs, a Unix style fs, a Mac OS fs - all made their
> mark on their systems, with permissions, valid file names and structure.

Right, and this is one of the big traps the Microsoft fell into with NT; they
didn't have routines for validating file specifications, permissions, etc. on a
per-file system basis.  Initially, NTFS supported lots of cool features,
including multiple versions of a file (just like VMS), but the Win32 API (which
is arguably one of the worlds ugliest) didn't understand file systems other than
FAT, so many of the cool features of NTFS were inaccessible and eventually
dropped.

 -Brian

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

I certainly wouldn't want to ignore the file system. What I'm suggesting is
that you could get a useful piece of an OS built without designing the file
system initially. To the extent that a Boot-Loader/Kernel/Core would need to
load programs to run, you'd have to connect to a file system of some sort,
but you could hide that beneath a package spec & just simulate it with some
existing file system. The point being that doing so you'd have something to
show & work with rather than creating so many requirements & raising so many
debates that nothing ever gets done. Better to have some simple piece of the
plan up and working and save the file system issues for later.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9n3h11$9ic1@news.cis.okstate.edu...
>
> But you don't want to fall into the trap of ignoring the file system.
> File systems are key part of an style - a FAT style fs, a VFAT style
> fs, a NTFS style fs, a Unix style fs, a Mac OS fs - all made their
> mark on their systems, with permissions, valid file names and structure.
>

Re: Ada OS talk (was: Progress on AdaOS)

[David Starner]

On Thu, 6 Sep 2001 09:59:11 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> I certainly wouldn't want to ignore the file system. What I'm suggesting is
> that you could get a useful piece of an OS built without designing the file
> system initially. To the extent that a Boot-Loader/Kernel/Core would need to
> load programs to run, you'd have to connect to a file system of some sort,
> but you could hide that beneath a package spec & just simulate it with some
> existing file system. 

Why would writing the code for some existing file system and the code to
make that system look like you want be any easier then writing some
simple file system that actually fits what you're trying to do? 

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

Well, think about it for a minute. If the initial objective is simply to get
something up and running and you've gone to the effort of building some
micro kernel & scheduler, then about all you need (initially) is some
ability to cause a program to be loaded from some source. You have not even
really got to the point where you have developed any serious device
drivers - just got code cycling in a box - so you're not concerned with
being able to run a sophisticated database app or anything like that yet.
You could dummy-up just enough of a file loader (hiden behind a package
spec) so that down the road, if you build your own file system (or interface
to NTFS, Unix, VMS, or anything else for that matter) you aren't in some
sort of major revision mode on your little core OS.

To design and build a full-blown file system is a *big* job. Just look at
everything that is in NTFS. Not to mention the fact that as is obvious here,
there are dozens of competing and incompatible strategies for designing one.
If you set as an objective getting a file system in place before releasing
anything, I admire the ambition, but I think it would cause the project to
languish. Obviously, you can go off and build anything you please and I'd be
the last one on the planet to try to stop you. I just think that it is too
ambitious for a first cut.

My idea for "Phase One"  would be to build just enough of an OS to be able
to boot it from a floppy & have a scheduler capable of loading some
pure-machine-code programs and have those programs up and cycling. You need
that much at minimum in order to accomplish anything else. You get the added
advantage that this much of an OS could be useful in embedded applications
where you have no file system, etc. Having a piece that big allows you to
hammer out the kernel and scheduling to get something that would make a
solid base for everything else.

But if you want to go write a file system - go right ahead.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
news:9n8o51$aik1@news.cis.okstate.edu...
>
> Why would writing the code for some existing file system and the code to
> make that system look like you want be any easier then writing some
> simple file system that actually fits what you're trying to do?
>

Re: Ada OS talk (was: Progress on AdaOS)

[Michael Garrett]

OAR had an Ada version of the RTEMS operating system a while back. I think
they have dropped support
for it, but I'm sure the source is available from them. This would probably
be a good starting point.

Michael C. Garrett



Marin David Condic <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9nala6$p3$1@nh.pace.co.uk...
> Well, think about it for a minute. If the initial objective is simply to
get
> something up and running and you've gone to the effort of building some
> micro kernel & scheduler, then about all you need (initially) is some
> ability to cause a program to be loaded from some source. You have not
even
> really got to the point where you have developed any serious device
> drivers - just got code cycling in a box - so you're not concerned with
> being able to run a sophisticated database app or anything like that yet.
> You could dummy-up just enough of a file loader (hiden behind a package
> spec) so that down the road, if you build your own file system (or
interface
> to NTFS, Unix, VMS, or anything else for that matter) you aren't in some
> sort of major revision mode on your little core OS.
>
> To design and build a full-blown file system is a *big* job. Just look at
> everything that is in NTFS. Not to mention the fact that as is obvious
here,
> there are dozens of competing and incompatible strategies for designing
one.
> If you set as an objective getting a file system in place before releasing
> anything, I admire the ambition, but I think it would cause the project to
> languish. Obviously, you can go off and build anything you please and I'd
be
> the last one on the planet to try to stop you. I just think that it is too
> ambitious for a first cut.
>
> My idea for "Phase One"  would be to build just enough of an OS to be able
> to boot it from a floppy & have a scheduler capable of loading some
> pure-machine-code programs and have those programs up and cycling. You
need
> that much at minimum in order to accomplish anything else. You get the
added
> advantage that this much of an OS could be useful in embedded applications
> where you have no file system, etc. Having a piece that big allows you to
> hammer out the kernel and scheduling to get something that would make a
> solid base for everything else.
>
> But if you want to go write a file system - go right ahead.
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
>
>
> "David Starner" <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message
> news:9n8o51$aik1@news.cis.okstate.edu...
> >
> > Why would writing the code for some existing file system and the code to
> > make that system look like you want be any easier then writing some
> > simple file system that actually fits what you're trying to do?
> >
>
>
>

Re: Ada OS talk (was: Progress on AdaOS)

[Marin David Condic]

I'm aware of RTEMS - it might make "A Good Start". My recollection of what
it was all about was that it might be a bit limited for a full-up OS. More
like an RTK and some device drivers to support an Ada implementation on a
bare board.

There might be licensing issues as well. I believe it is GPL - don't know
the specifics - but it might not be A Good Thing to force any additional
work to fall under the GPL. (That's an opinion - others may differ on that.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Michael Garrett" <michaelgarrett@csi.com> wrote in message
news:9nhbjd$dcg$1@suaar1aa.prod.compuserve.com...
> OAR had an Ada version of the RTEMS operating system a while back. I think
> they have dropped support
> for it, but I'm sure the source is available from them. This would
probably
> be a good starting point.
>

Re: Ada OS talk (was: Progress on AdaOS)

[Joel Sherrill]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in message news:<9nigt5$490$1@nh.pace.co.uk>...
> I'm aware of RTEMS - it might make "A Good Start". My recollection of what
> it was all about was that it might be a bit limited for a full-up OS. More
> like an RTK and some device drivers to support an Ada implementation on a
> bare board.

Correct RTEMS is what used to be called an executive or kernel.  It is
not as limited as you might think though with major features like 
TCP/IP, filesystem, about 85% of POSIX 1003.1b, uITRON, and a pSOS+-like API 
ported to about a dozen CPUs.

> There might be licensing issues as well. I believe it is GPL - don't know
> the specifics - but it might not be A Good Thing to force any additional
> work to fall under the GPL. (That's an opinion - others may differ on that.)

RTEMS is GPL'ed with the same type of exception as the GNAT run-time.

> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
> 
> 
> "Michael Garrett" <michaelgarrett@csi.com> wrote in message
> news:9nhbjd$dcg$1@suaar1aa.prod.compuserve.com...
> > OAR had an Ada version of the RTEMS operating system a while back. I think
> > they have dropped support
> > for it, but I'm sure the source is available from them. This would
>  probably
> > be a good starting point.

It has been a long time but it can be dug up. :)  

When it was new, there was very little 
feedback to it.  The C implementation got a lot more interest
and when the C version was used as the run-time for GNAT,
it seemed to satisfy the same goal without duplicating 
effort.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: Ada OS talk (was: Progress on AdaOS)

[Michael Garrett]

I may not understand the whole picture.... ( been in managment for a while )
but
the original Ada version of rtems could be put on top of a hardware
abstraction layer, with minimal
amount of assembly, ( it probably was impelmented this way ) forming a micro
kernel, which could be the foundation of the operating system.

With suitable layers on top of this foundation ( GNORT compiled, or no
runtime ), a runtime could be provided that GNAT could call into, providing
a full Ada runtime environment on top of an all Ada kernel.

( I'm in over my head but you get the picture ).

What I think this would provide is deterministic behavior. If an all Ada OS
is to be considered, my opinion
is that it should be deterministic to a hard realtime level. This is a lofty
goal, but starting with a deterministic
all Ada micro kernel is  a good start.

QNX is built this way, on top of a small scalable micro kernel. If the goal
is an all Ada scalable OS this seems
to be an ideal way to leverage the work already done by OAR, the all Ada
micro kernel.



Michael C. Garrett
michaelgarrett@csi.com

Joel Sherrill <joel@OARcorp.com> wrote in message
news:608f3869.0109101239.5b9fdde2@posting.google.com...
> "Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:<9nigt5$490$1@nh.pace.co.uk>...
> > I'm aware of RTEMS - it might make "A Good Start". My recollection of
what
> > it was all about was that it might be a bit limited for a full-up OS.
More
> > like an RTK and some device drivers to support an Ada implementation on
a
> > bare board.
>
> Correct RTEMS is what used to be called an executive or kernel.  It is
> not as limited as you might think though with major features like
> TCP/IP, filesystem, about 85% of POSIX 1003.1b, uITRON, and a pSOS+-like
API
> ported to about a dozen CPUs.
>
> > There might be licensing issues as well. I believe it is GPL - don't
know
> > the specifics - but it might not be A Good Thing to force any additional
> > work to fall under the GPL. (That's an opinion - others may differ on
that.)
>
> RTEMS is GPL'ed with the same type of exception as the GNAT run-time.
>
> > MDC
> > --
> > Marin David Condic
> > Senior Software Engineer
> > Pace Micro Technology Americas    www.pacemicro.com
> > Enabling the digital revolution
> > e-Mail:    marin.condic@pacemicro.com
> > Web:      http://www.mcondic.com/
> >
> >
> > "Michael Garrett" <michaelgarrett@csi.com> wrote in message
> > news:9nhbjd$dcg$1@suaar1aa.prod.compuserve.com...
> > > OAR had an Ada version of the RTEMS operating system a while back. I
think
> > > they have dropped support
> > > for it, but I'm sure the source is available from them. This would
> >  probably
> > > be a good starting point.
>
> It has been a long time but it can be dug up. :)
>
> When it was new, there was very little
> feedback to it.  The C implementation got a lot more interest
> and when the C version was used as the run-time for GNAT,
> it seemed to satisfy the same goal without duplicating
> effort.
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel@OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985

Re: Ada OS talk (was: Progress on AdaOS)

[David Starner]

On Fri, 7 Sep 2001 10:24:04 -0400, Marin David Condic <dont.bother.mcondic.auntie.spam@[> wrote:
> To design and build a full-blown file system is a *big* job. Just look at
> everything that is in NTFS.

Based on what people have mentioned about NTFS, it has serious feature 
bloat; having features that can't be accessed from the API are a waste.
I wasn't talking about implementing a journalled, efficent filesystem
from the start; I was talking about implementing a quick and dirty 
filesystem that reflects the way the OS works.

-- 
David Starner - dstarner98@aasaa.ofe.org
Pointless website: http://dvdeug.dhis.org
"I don't care if Bill personally has my name and reads my email and 
laughs at me. In fact, I'd be rather honored." - Joseph_Greg

Re: Ada OS talk (was: Progress on AdaOS)

[Darren New]

> > Right. The hardware is going to enforce this. But I don't want to reveal
> > a storage-element level as a building block for directories, for
> > example.
> 
> You are thinking Unix again ;-)  Dont!

Well, no, avoiding recreating UNIX is just what I've been advocating. My
point is that saying "everything is based on storage elements" is
pointless if at some point you hide storage elements from the
application. Just like if you support demand-paged virtual memory, you
hide physical memory addresses from applications. Of course, a kernel is
going to know about physical memory addresses, as it's the one doing the
paging. But the API to the kernel need never know about physical memory
addresses. (At least for things like desktop apps. Of course, realtime
apps etc might want that info.)

> > > By serialization you mean a (do_first, do_next, end_error) sort of thing?
> > No, I mean flattening into something that has to be parsed.
> OK.  Them it is definitely an outer layer (w.r.t. the kernel).

Sorry. I'm not sure what that means.
 
> > > I think the best building block is the (un)bounded array of storage
> > > elements, which is more than this.  But of course I may be wrong.
> >
> > It's a good low-level building block, but it's not a good higher-level
> > building block. I think records are good. I think the ability to insert
> > and delete records is good. I think the ability to have at least one and
> > maybe many ordered indicies on records is good.
> 
> I meant the best _low_level_ building block.  Then a middle level layer
> would provide records etc. but this edifice needs bricks.

Well, considering that I don't know of any memory hardware that isn't
based on some equivalent of storage elements, this is a kind of
meaningless statement, yes? "We should base our operating system on
assuming the hardware has RAM."  Errr, OK. Sure.

I was discussing what kind of API the OS and/or kernel should present to
application programs.

Am I misunderstanding your point?

> The point was that _both_ directories and file types are similarly above
> kernel level, without hindering coherency or performance.

Well, actually, I thought that was the question being discussed. Namely,
what *is* the kernel layer?

> Not important an issue really at this point.  Hmmm... what point?  I would
> expect this talk would result in a sort of strategic plan for building an
> OS as a hobby by Adaists.  To that effect I propose a generic principle of
> simplicity/smallness.  That is why my messages have a general "downsizing"
> tone.  Remember the fall of the AdaOS.

Yes. But nothing I've suggested is really radical or complicated. Poorly
described, perhaps.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.