From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3e1162e6041216070874f424e5@mail.gmail.com> Date: Thu, 16 Dec 2004 07:08:34 -0800 From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Acme mailreader In-Reply-To: <8c28239dd33c04e668032c40d598e778@collyer.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <8c28239dd33c04e668032c40d598e778@collyer.net> Topicbox-Message-UUID: 18bc75e8-eace-11e9-9e20-41e7f4b1d025 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 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.