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,6394e5e171f847d1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-05 09:02:44 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!newsfeed.wirehub.nl!195.129.110.18.MISMATCH!bnewspeer00.bru.ops.eu.uu.net!emea.uu.net!newsfeed.siemens.de!news.mch.sbs.de!not-for-mail From: Alfred Hilscher Newsgroups: comp.lang.ada Subject: Re: Ada OS Kernel features Date: Wed, 05 Sep 2001 18:02:02 +0200 Organization: Siemens AG Message-ID: <3B964C7A.BC04374E@icn.siemens.de> References: <9n4euv$t9m$1@slb6.atl.mindspring.net> NNTP-Posting-Host: 139.21.122.158 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:12754 Date: 2001-09-05T18:02:02+02:00 List-Id: Brian Catlin wrote: > > What sort of features would be desirable/required in the kernel? > > Processor architectures: > What sort of processor architectures should be supported? 32-bit obviously, > but what about 64-bit, or 16-bit? Little-endian only, or big-endian too? 32-bit open for future 64-bit. Both, _big_ and _little_ endian. > (personally, I view big-endian as a crime against nature, and would vote against Why ? > processors) Deciding on these issues early is very important, as it will > greatly influence the rest of the design and implementation of the kernel. All In which manner? Where do you think that there will be any influence? > Memory management: > A demand-paged memory manager would seem to be required. However, I would not > like to see paging made a requirement - as long as there is enough physical > memory, there should be no need. Thats what I liked on OS/2, one was able to switch it off. > process an I/O request is passed around between drivers. What form should a > driver take? Implementing a driver as one or more tasks in the kernel seems to > be the most natural. The layering of device drivers (as implemented) in NT > would also seem to be a very valuable feature. You should be able to load/unload a driver dynamically (I hate rebooting because of driver change). You should be able to "overload" a driver. What I mean ? Lets assume you have a simple grafic driver on bootup, then you load a "better" (more complex, higher resolution, 3D excelerator ...) one. If this one crashes, then it should simply be unloaded and the system should continue work with the (simple) default driver - instead of showing a "blue screen" ;-)