Re: Ada OS Kernel features

["Brian Catlin" <briancatlin@mindspring.com>]

"Alfred Hilscher" <Alfred.Hilscher@icn.siemens.de> 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