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-08-31 13:00:07 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!cyclone1.gnilink.net!news-east.rr.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com!not-for-mail Message-ID: <3B8FECC4.92C5D589@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: Progress on AdaOS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 31 Aug 2001 20:00:07 GMT NNTP-Posting-Host: 24.165.20.229 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 999288007 24.165.20.229 (Fri, 31 Aug 2001 13:00:07 PDT) NNTP-Posting-Date: Fri, 31 Aug 2001 13:00:07 PDT Xref: archiver1.google.com comp.lang.ada:12624 Date: 2001-08-31T20:00:07+00:00 List-Id: "M. A. Alves" wrote: > > > > > If you're building an AdaOS, why not make files that are managed with > > > > Ada semantics? > > > > > > My view is close to that. ADTs. File = persistent (un)bounded array of > > > storage element (plus user and permission information). Dir = persistent > > > (un)bounded array of files (plus ditto). > > > > But why limit a file to an array of storage elements? Why not persistant > > unbounded storage pool? Or persistant unbounded tagged classwide type? > > Or persistant protected object? > > . . . > > Hmmm... Different levels, I guess. I think a _kernel_ should deal with > storage elements alone. Higher levels (e.g. a file of integers) would be > an elaboration upon that. Not the OS role. Making a strict separation like that is exactly the kind of thing that causes mental impedence mismatch. It's the same kind of reasoning that says "let the language deal with processes, and save threading for a library." :-) Of course, the kernel deals with storage elements, because that's all there really is. That's why we have compilers, to distinguish pointers from integers from floats. :-) It's a question of how the kernel presents those storage elements to a program. For example, mmap() deals with storage elements *and* files, and if you build a storage_pool that used mmap, you could (perhaps) allocate stuff from the storage pool, then stop your process, start up a different one, and use the complex data structures that are in that storage pool. On the other hand, FORTH really *does* use *only* storage elements. That means no directories and no files. Your disk really is an array of storage elements. Directories are the responsibility of your code. Is that really what you want in a kernel? It's not a question of "high level" vs "low level". It's just a question of where you draw the boundary in a continuous series of levels. And thinking that knowing that the "type" of the data in the file is image/gif is vital, but being willing to read the file to find out of it's GIF87 or GIF89 is OK too doesn't make sense to me. And saying "this is an image file, and that fact cannot change without a change in the data" and then letting programs copy the raw bytes is just silly too. > Basically yours is the radical OO view = high hierachies vs. a kind of > bottom-up approach to OS development = microkernel. I tend to favour the > latter, but perhaps a blend is possible. Hmmm... You can still do it as a microkernel. It's the programs defining the format, not the kernel. The kernel just has to allow persistant storage of something other than storage elements. In particular, the language has to have a binding such that the fact that everything's really storage elements at the bottom is hidden by the type system. I think Ada is powerful enough to have such ideas integrated seemlessly. I don't know why else you'd want to write an OS in Ada, other than as practice with Ada and OSes. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand.