From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-03 11:11:21 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newsfeed1.cidera.com!Cidera!cyclone1.gnilink.net!news-east.rr.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com!not-for-mail Message-ID: <3B93C7BE.78A45678@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada OS talk (was: Progress on AdaOS) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 03 Sep 2001 18:11:12 GMT NNTP-Posting-Host: 24.165.20.19 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 999540672 24.165.20.19 (Mon, 03 Sep 2001 11:11:12 PDT) NNTP-Posting-Date: Mon, 03 Sep 2001 11:11:12 PDT Xref: archiver1.google.com comp.lang.ada:12664 Date: 2001-09-03T18:11:12+00:00 List-Id: "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.