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

[Darren New <dnew@san.rr.com>]

"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.