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

["Robert C. Leif, Ph.D." <rleif@rleif.com>]

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