Re: vOSiX, was: Re: Darwin Streaming Server 3.01 running on YDL


Subject: Re: vOSiX, was: Re: Darwin Streaming Server 3.01 running on YDL
From: Timothy A. Seufert (tas@mindspring.com)
Date: Tue Aug 28 2001 - 20:02:08 MDT


At 8:18 PM -0400 8/28/01, Robert Vogt IV wrote:
>> What does this mean for us as current and presumably long-term YDL
>> users. Does it mean that we can look forward to an Orange Puppy Linux
>> that avoids all these driver problems.
>
> Well, it wouldn't be Linux. :) But yes, licensing would be about
>the same, and it'll be open source. The goal is to produce an
>architecturally better OS while maintaining compatibility with the
>majority of Linux software.

If it's to be "architecturally better" I'm afraid you're starting
from false premises, both about what is better and what the current
state of Linux is. I believe you have cited three major potential
advantages: microkernel design, OOP, and better hardware abstraction.

Microkernel is not necessarily better than monolithic.
Maintainability and stability come from good design, not
microkernel-ness, and Linux already has good design.

OO is not appropriate for many parts of an operating system kernel.
But where it is appropriate, Linux already uses it. You do not have
to use an OOP language to do OO programming techniques; look at the
Linux VFS and Linux file systems for an example of how Linux uses OO
techniques in C. It is not uncommon for some of the core Linux
developers to talk about "methods" and such, because they are quite
aware that parts of the system are really OO.

Finally, Linux already has plenty of hardware abstraction in the
right places. The core kernel (scheduler, VM, etc.) has very few of
the hardware specific constructs you complain about:

[tas@bigblue build24]$ rgrep -R '*.[ch]*' "#if.*__.*__" arch/ | wc -l
     209
[tas@bigblue build24]$ rgrep -R '*.[ch]*' "#if.*__.*__" drivers/ | wc -l
     719
[tas@bigblue build24]$ rgrep -R '*.[ch]*' "#if.*__.*__" fs/ | wc -l
     103
[tas@bigblue build24]$ rgrep -R '*.[ch]*' "#if.*__.*__" include/ | wc -l
    1519
[tas@bigblue build24]$ rgrep -R '*.[ch]*' "#if.*__.*__" init/ | wc -l
       1
[tas@bigblue build24]$ rgrep -R '*.[ch]*' "#if.*__.*__" ipc/ | wc -l
       2
[tas@bigblue build24]$ rgrep -R '*.[ch]*' "#if.*__.*__" kernel/ | wc -l
      18
[tas@bigblue build24]$ rgrep -R '*.[ch]*' "#if.*__.*__" lib/ | wc -l
       0
[tas@bigblue build24]$ rgrep -R '*.[ch]*' "#if.*__.*__" mm/ | wc -l
       0
[tas@bigblue build24]$ rgrep -R '*.[ch]*' "#if.*__.*__" net/ | wc -l
       5

(Note: the grep construct used above will cause false positives, but
matches #if __i386__ etc.)

The arch specific code is in arch, drivers, and include for the most
part, just where you'd expect it to be. The kernel is the system's
hardware abstraction layer; more internal abstraction layers would
likely be bloat.

#if is ugly, and Linus Torvalds wants to start replacing it in 2.5
with simple C if constructs. The compiler (gcc) is good enough that

         if (__ppc__) {

         } else {

         }

is equivalent to

#ifdef __ppc__

#else

#endif

because as long as __ppc__ evaluates to a constant at compile time,
gcc can remove the dead branch of code as if it wasn't there.

(In the present kernel, __ppc__ isn't be defined at all if you are
compiling for a different arch. The proposed change would always
define __ppc__ and other options to be 0 or 1 for use in "if"
constructs as above.)

>> Does it mean that the Church
>> of Linus has false doctrine, that microkernel architectures really
>> are superior?
>
> It depends. A microkernel architecture is far more stable and
>error-resiliant.

What makes you think that microkernel design is a magic bullet that
makes the system "stable and error-resiliant"?

>However, a monolithic kernel is faster, since everything
>resides within one process. We're going for a combination - microkernel
>code architecture, but monolithic run-time. :)

IOW, it's really a monolithic kernel, but somebody still believes
enough in the microkernel religion to want to call it one. :)

-- 
Tim Seufert



This archive was generated by hypermail 2a24 : Tue Aug 28 2001 - 19:10:29 MDT