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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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 12:12:04 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!oleane.net!oleane!freenix!enst!enst.fr!not-for-mail From: "M. A. Alves" Newsgroups: comp.lang.ada Subject: Re: Ada OS talk (was: Progress on AdaOS) Date: Mon, 3 Sep 2001 20:12:47 +0000 (GMT) Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: avanie.enst.fr 999544314 56029 137.194.161.2 (3 Sep 2001 19:11:54 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Mon, 3 Sep 2001 19:11:54 +0000 (UTC) To: Return-Path: X-X-Sender: In-Reply-To: <3B93C7BE.78A45678@san.rr.com> Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.4 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:12668 Date: 2001-09-03T20:12:47+00:00 > > > 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