Re: [9fans] Acme mailreader

[David Leimbach <leimy2k@gmail.com>]

hmmm not sure where this all came from on this thread of discussion :).


On Wed, 15 Dec 2004 16:24:47 -0800, geoff@collyer.net <geoff@collyer.net> wrote:
> OS X is in no sense a micro-kernel.  The OS X kernel is huge:
> 
>         ; size /mach_kernel
>         __TEXT  __DATA  __OBJC  others  dec     hex
>         3022848 458752  0       643984  4125584 3ef390
> 
> and consists of a heavily-hacked Mach (3, I believe) kernel and a
> FreeBSD kernel (with bits from other BSDs), combined into a single
> kernel and running in a single address space.  The BSD kernel does not
> run in user mode.  Remember that Mach was, as far as I know, the
> largest ``micro-kernel'' ever produced, larger than most or all of its
> contemporary ``macro-kernels'', so that some of us called it a
> ``Machro-kernel''.

It's an OSF Mach3 with "optimizations" :).  The kernel is really
nothing like FreeBSD.  It's more like the BSD from NeXTStep with some
Free/Open/Net BSD stuff hacked in.  Also you are forgetting IOKit [the
C++ framework for device drivers].

The Apple marketing team is just putting rubbish on the internet when
it comes to claiming things are based on FreeBSD 5.

In fairness, some of the userland applications and command line tools
are, in fact, from FreeBSD but the amount of FreeBSD in XNU [the
kernel] and Darwin is exaggerated.  Porting things from FreeBSD 5,
however to Mac OS X is quite painful because you have to deal with
IOKit and the hardly FreeBSD-like bsd kernel portion.


> 
> I haven't looked very hard (one could check out the mount_* sources
> from the Darwin CVS servers), but mount(2) doesn't seem to have much
> that's new, except for union mounts, which surprised me.  I suspect
> that most of the mount_* commands either invoke kernel machinery
> (through the ``type'' argument to mount) or pretend to be NFS servers.
> I've never yet seen a (l)unix system other than late Research Unix
> that made user-mode file servers relatively easy and painless to write
> (though I'd love to be shown a counter-example!).  Of course, since
> many (l)unix systems only allow the super-user to mount anything,
> their maintainers may not see much utility in user-mode file servers.
> It's sort of a cascade of vision-failures.

Maybe because people don't know why Plan 9 is better than Unix they
thing Unix is "the way".  Religion often overrides common sense.  Do
we need more plan 9 "missionaries"? [probably]

DragonflyBSD is working on making the VFS a message passing layer
instead of a system call layer so doing something like 9p is probably
already in their grand scheme of development.

http://www.dragonflybsd.org/goals/vfsmodel.cgi

This doesn't help Mac OS X of course.

> 
> Also, /sys/src/cmd/upas/README is a little dated:
> 
>         --rw-rw-r-- M 5174 sys sys 1041 Dec 11  1999 README
> 
> I'm not sure if it pre-dates upas/fs, but it describes how to port the
> parts of upas that don't rely on Plan 9 facilities (transport more
> than reading).  I ported Plan 9's upas back to Unix while at the labs
> (and also translated it into limbo), but some parts (e.g., upas/fs)
> didn't have an obvious implementation, other than painfully pretending
> to be an NFS server, at least at the time.
> 

Might be interesting to see how DragonFlyBSD has come along and if
it's possible to implement upas/fs with whatever they've done.

Again this doesn't really help Mac OS X.

I just think it's interesting.