Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Dec 2000 12:27:55 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.ORG>
To:        Jordan Hubbard <jkh@winston.osd.bsdi.com>
Cc:        Patryk Zadarnowski <pat@jantar.org>, Tony Finch <dot@dotat.at>, SteveB <admin@bsdfan.cncdsl.com>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: kernel type 
Message-ID:  <Pine.NEB.3.96L.1001217121531.48123B-100000@fledge.watson.org>
In-Reply-To: <85112.977020676@winston.osd.bsdi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 16 Dec 2000, Jordan Hubbard wrote:

> > PS. Before this starts a flame war, let me say that I really believe
> > that MacOS X is a very good thing for everyone involved, although the
> > choice of Mach for the microkernel seems a little arbitrary if not
> > misguided.
> 
> It's hardly arbitrary, though the jury's still out as to whether it's
> misguided or not.  You may remember that Apple bought a little company
> called NeXT a few years back.  Well, that company's people had a lot
> to do with the OS design of OS X and let's not forget the design of
> NeXTStep.

The Darwin kernel is a microkernel in only a few senses of the word.  It
does have a small central code component that provides primitives for
context and address space management, message passing, and so on.  It does
allow you to layer a variety of "personalities" on top of it providing the
full functionlity of traditional operating systems with greater modularity
and nice distributed system properties.  However, it's also a monolithic
kernel in the sense that it runs in a single address space, and the BSD
personality included fits quite well in the "monolithic" definition, given
that it's a large chunk of the FreeBSD kernel.

Personally, I think their design has some nice properties, and that it was
the right choice for them at the time.  They had a large existing,
well-designed and architected kernel environment based on a combination of
Mach and BSD (NeXTStep), which already had all the right primitives and
implementation for a highly scalable, multi-threaded, multi-processor
kernel environment.  When they branched the FreeBSD code, it was barely
multi-processor, let alone multi-threaded.  They took the best of the
FreeBSD world (mature userland, mature network stack, well-defined ABI and
API, POSIX-like libraries, liberal license), and replaced much of the old
NeXTStep (BSD 4.3?) equivilents.

Given that FreeBSD is now moving in the direction of greater architectural
maturity in terms of kernel synchronization primitives allowing
fine-grained kernel threading, strong SMP support, multi-platform support,
I would expect that a sensible course would be to try and resolve some of
the code-base difference between the two platforms, allowing Apple to
continue to track our developments while retaining their proprietary
userland environment.  In particular, it would be nice to re-converge on
locking/VFS/threading/SMP issues where possible.

I actually like their HFS+ file system a lot (although I'd throw out the
hard link hack, and hard links themselves) as it offers high performance
directory operations. I'd fix their weird VOP's that try to take advantage
of that, and work with them to fix the VFS problems that must hound them
as much as us.  I'd also work with them to integrate back some of their
NFS fixes. 

I think that the determining factor for the success or failure of OS X is
not its kernel architecture -- it's whether or not their userland
interface diverges sufficiently from the OS 9 interface that their user
base doesn't follow them to the new platform.  The interface is what will
make or break OS X; thus far they've managed to hide most of the nastiness
of UNIX by adopting the NeXTStep netinfo configuration and directory
service environment -- I've been seriously considering looking at adapting
FreeBSD to use netinfo also, given that it provides a time-tested model
for configuration management (local and distributed).  It probably needs
some cleaning up in the security sense, and possibly rewriting, but it's a
strong starting point, and liberally licensed.  What runs under that
doesn't matter as long as Apple can support it and provide extensibility
required by hardware vendors (their IOKit provides a fixed and
object-oriented API for providing device support and management, and we
should be comparing newbus to it and seeing what we missed :-).

I'm impressed by their work and by their vendor support -- it comes
shipped with Internet Explorer as the default native browser, and has
strong commitments for native versions from software vendors such as Adobe
and Microsoft -- the first UNIX system I've seen that does that while
remaining a desktop pricetag.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1001217121531.48123B-100000>