Re: [9fans] Acme mailreader

[geoff@collyer.net]

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

I worked at Apple in the BSD group.

The XNU non-Mach code was clearly some BSD kernel and I don't really
care which.  My colleagues told me it started out with NetBSD but that
that was eventually dwarfed by FreeBSD with contributions from
elsewhere.  While I was there, there was talk of dragging in code from
the latest FreeBSD, notably the FFS with soft updates; I'm pretty sure
that happened.  Given that the group was (and probably still is)
headed by Jordan Hubbard of FreeBSD fame, I suspect that they're
continuing to pull in FreeBSD code and it isn't just hype.

Note too that the XNU BSD code, measured in source lines, is almost
exactly as huge as the Mach code, so the volume of *BSD code in XNU is
not, in my opinion, exaggerated: it is (or was in 2002) half the
kernel source.  (I don't remember which side of the fence IOKit was
counted against.)

Yes, the XNU kernel details are different from a stock BSD kernel.  It
co-exists with Mach, after all.  Porting graphical applications to
native OS X (avoiding X11) is a pain too; Apple do a lot of things
their own way, inheriting baggage from the pre-Unix Mac OS and
NextStep (netinfo is just the French spelling of `Yellow Pages', ugh).

Nevertheless, I stand by my statement that OS X is in no sense a
micro-kernel, and that user-mode file servers will not (as a result of
access to a micro-kernel) be easier to implement on OS X than on other
(l)unixes.

However, Martin Atkins has revealed the mystery kernel agent: coda.
Apparently it's somewhat specialised but lets user-mode file servers
catch opens and closes.

Anyone in (l)unixland for a filesystem switch?  Research Unix had one
~20 years ago, so it should be mouldy (er, mature) enough to be
acceptable to (l)unixland.  Throw in mounts by ordinary users and use
of 9P as an unifying filesystem protocol (now pretty well aged in Plan
9), and it becomes possible to push lots of code and some hacks out of
the kernel, while permitting some new and interesting work.

[-- Attachment #2: Type: message/rfc822, Size: 6546 bytes --]

From: David Leimbach <leimy2k@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Acme mailreader
Date: Thu, 16 Dec 2004 07:08:34 -0800
Message-ID: <3e1162e6041216070874f424e5@mail.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.