From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9ccf822edf0a9a77c141ae47312638dd@collyer.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] Acme mailreader Date: Thu, 16 Dec 2004 15:22:59 -0800 From: geoff@collyer.net In-Reply-To: <3e1162e6041216070874f424e5@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-wpiucwdjaqdapfjrwiwqyrjniq" Topicbox-Message-UUID: 19a0597a-eace-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-wpiucwdjaqdapfjrwiwqyrjniq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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. --upas-wpiucwdjaqdapfjrwiwqyrjniq Content-Type: message/rfc822 Content-Disposition: inline Received: from collyer.net ([216.240.55.183]) by collyer.net; Thu Dec 16 07:09:13 PST 2004 Received: from mail.cse.psu.edu ([130.203.4.6]) by collyer.net; Thu Dec 16 07:09:11 PST 2004 Received: from psuvax1.cse.psu.edu (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 553CCC6B19 for ; Thu, 16 Dec 2004 10:08:57 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: from localhost (localhost [127.0.0.1]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 7EDF9C6790 for <9fans@cse.psu.edu>; Thu, 16 Dec 2004 10:08:42 -0500 (EST) Received: from mail.cse.psu.edu ([127.0.0.1]) by localhost (psuvax1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13528-01-13 for <9fans@cse.psu.edu>; Thu, 16 Dec 2004 10:08:35 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 9C0EBC6A73 for <9fans@cse.psu.edu>; Thu, 16 Dec 2004 10:08:35 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 57so11648wri for <9fans@cse.psu.edu>; Thu, 16 Dec 2004 07:08:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=KE98UHqs35HImwhRTwPxC8hNTKtpIXbMDjK0s06DR/7ZKRl3FSScsiNxytRTgUi4EPhrXABURyyhzLvFvOjoKWUYM6rvoIL7XHeobmQlbFwF7bRl4x5b2sz7T/jL6o17yO4soCFKatBPxBuIPcTEpFWn7B0r/tHQyG8f3TY1I4A= Received: by 10.54.10.55 with SMTP id 55mr1664205wrj; Thu, 16 Dec 2004 07:08:34 -0800 (PST) Received: by 10.54.18.47 with HTTP; Thu, 16 Dec 2004 07:08:34 -0800 (PST) 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> X-Virus-Scanned: by amavisd-new at cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Leimbach , Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces+geoff.9fans=collyer.net@cse.psu.edu Errors-To: 9fans-bounces+geoff.9fans=collyer.net@cse.psu.edu 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. --upas-wpiucwdjaqdapfjrwiwqyrjniq--