Subject: Re: vOSiX, was: Re: Darwin Streaming Server 3.01 running on YDL
From: Robert Vogt IV (robert@arborhost.com)
Date: Wed Aug 29 2001 - 09:49:34 MDT
Tim,
> 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.
Before we get into a religious war, let me lay out the goal of the
project. The _GOAL_ is to produce an "architecturally better" OS. Input
from all sides as to what that constitutes is fully acceptable and
encouraged. Those wishing to contribute can email me directly.
> Microkernel is not necessarily better than monolithic.
> Maintainability and stability come from good design, not
> microkernel-ness, and Linux already has good design.
No. First of all, I stated that Microkernel and Monolithic
architectures each have advantages and disadvantages. Number 1, a quick
glance at the Linux source indicates it is full of unfinished hacks, etc
(ACLs for example). A Monolithic kernel is _generally_ faster, since
everything is encapsulating into one running block. With a Microkernel,
the major system services run as processes under a miniature
(micro) kernel, so there is some overhead (although there is the ability
to recover if the services have bugs in them). We're going for a mix -
the code is laid out in a Microkernel format, (the architecture-dependent
portion which handles the core system), but the rest of the OS services
are linked into the same functional code block. (The advantages of each
architecture is the idea here...)
> 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.
They may be OO, but they're "weak" OO. Classes, inheritance, etc
are necessary for a truly OO approach. That said, its much more difficult
to dynamically link classes, etc into a running kernel. :)
> 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:
Take a look at the book "Linux Internals" - the authors talk quite
a bit about a lack of abstraction. My concept is to abstract all
hardware-dependent code to a single class (the coresystem class),
preventing namespace pollution (a big problem in Linux, IMHO).
> 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.
This is where I disagree. The architecture-specific code should
be in arch (or adc, as we call it) only.
> #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
<snip>
> (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.)
>
> What makes you think that microkernel design is a magic bullet that
> makes the system "stable and error-resiliant"?
See above - its all about partitioning. That said, it doesn't
mean the system _MUST_ be more reliable, it simply means there are fewer
failure points.
> IOW, it's really a monolithic kernel, but somebody still believes
> enough in the microkernel religion to want to call it one. :)
Well, again, this is a matter of religion. I really don't care
what it is, as long as its clean code, and runs fairly quickly. ;)
Sincerely,
Robert Vogt IV
This archive was generated by hypermail 2a24 : Wed Aug 29 2001 - 08:57:55 MDT