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-04 10:19:09 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!feed2.news.rcn.net!rcn!cpk-news-hub1.bbnplanet.com!news.gtei.net!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: <3B950AB9.533F06E3@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: Tue, 04 Sep 2001 17:09:15 GMT NNTP-Posting-Host: 24.165.20.19 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 999623355 24.165.20.19 (Tue, 04 Sep 2001 10:09:15 PDT) NNTP-Posting-Date: Tue, 04 Sep 2001 10:09:15 PDT Xref: archiver1.google.com comp.lang.ada:12709 Date: 2001-09-04T17:09:15+00:00 List-Id: > > 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.