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 10:45:07 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!feed2.news.rcn.net!rcn!newsfeed1.earthlink.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail From: "Brian Catlin" Newsgroups: comp.lang.ada Subject: Re: Ada OS Kernel features Date: Wed, 5 Sep 2001 10:44:19 -0700 Organization: Sannas Consulting Message-ID: <9n5o9n$37a$1@slb7.atl.mindspring.net> References: <9n4euv$t9m$1@slb6.atl.mindspring.net> <3B964C7A.BC04374E@icn.siemens.de> NNTP-Posting-Host: d1.56.dc.81 X-Server-Date: 5 Sep 2001 17:44:23 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xref: archiver1.google.com comp.lang.ada:12762 Date: 2001-09-05T17:44:23+00:00 List-Id: "Alfred Hilscher" wrote in message news:3B964C7A.BC04374E@icn.siemens.de... > > > 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 ? I don't want to start a flame war, or get too far off topic, but big-endian just doesn't make sense (at least compared to little-endian). In little-endian, you count your bits and bytes from right to left, all the way to infinity. In big-endian, what purpose does swapping the bytes around have? Also, communications between a big-endian and little-endian system is a pain in the neck. Intel's x86 may be a lousy architecture, but in my opinion it has done at least one good thing: it has virtually eliminated big-endian machines. The only big companies making big-endian systems are IBM, Motorola, and Sun. While it is true that they could be called "heavy weights", their market share as a percentage of the x86 is miniscule. > > 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? This is one of the lessons learned from NT, which at one time supported 4 very different processor architectures. Unfortunately, they chose the MIPS as one of their targets, and the repercussions were felt all over the operating system, as the MIPS was a lot less capable that the other architectures (x86, PPC, Alpha). One of the most notable problems was that the early MIPS processors didn't support 4 processor modes (as I remember, it only supported two; user mode and supervisor mode). > > 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). Agreed. This is not simple to implement, but it is well worth the trouble > 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" ;-) My first reaction to this was "Not Possible". However, that isn't entirely true; it is just *VERY VERY* difficult. A driver runs in kernel mode, and has access to system data structures. If a driver corrupts a system data structure, how do you detect this, repair it, and continue? In such instances, it is much better to bugcheck (blue screen) the system than try to continue. Consider, if the system is slightly corrupted and continues to operate, there is the very real possibility that your data will be corrupted without your knowledge. This was Win98's philosophy, and it was a disaster. VMS and NT (and others) stop the system dead in its tracks to prevent hidden corruption. -Brian