Date: Sun, 20 Sep 1998 21:51:45 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter@netplex.com.au (Peter Wemm) Cc: jkh@time.cdrom.com, freebsd@timog.prestel.co.uk, current@FreeBSD.ORG Subject: Re: DEVFS & SLICE? Message-ID: <199809202151.OAA02593@usr04.primenet.com> In-Reply-To: <199809201928.DAA02596@spinner.netplex.com.au> from "Peter Wemm" at Sep 21, 98 03:28:17 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I think Julian's Big Mistake (TM) was bundling the SLICE option with the > nifty root and /dev bootstrap system. They don't really seem to be related > and they seem to get easily mixed up.. Julian first described his design > for 'slice' to me over 2 years ago, and I thought back then that it was > ambitious and was going to be an uphill battle. See other posting. This problem occurs because the system insists on making a distintion between root and non-root mounts ate the FS level. This leads to a plethora of code duplication, and a hell of a lot of potential problems. My complaint about the SLICE code is that it assumes an external agency will do the disklabel/partition/extended-partition/etc. hacking on a raw device (i.e., that there is a user space program, rather than an ioctl(), that abstracts paritioning schemas). Given the f-ed-up nature of the VFS mount code, it's not surprising that there should be trouble. I think SLICE did us a great service when it pointed out that the MFS implementation was a kludge-on-a-kludge. The use of direct calls to specfs in order to call back into the MFS strategy routine for bmap/getpage/putpages shows that MFS is a gross hack, and needs to be fixed. That the SLICE code was backed out instead of the MFS code fixed is more of a tribute to the necessity of having a working (if half-assed) MFS being important for the 3.0 release deadline, and people being willing to do one kind of work (tree reversion) as opposed to another (fixing MFS and/or writing a memory device driver that uses a kernel process as a VM container context for the MFS data loaded off the boot disk, and FFS-formating it, as a stopgap measure). This is, I think, a rather natural consequence of setting deadlines in a volunteer organization, and so there's really nowhere to formally lay the blame. But this has nothing to do with Julian's failing/merits as an architect (even if I personally don't like aspects of the architecture he came up with, for my own reasons -- i.e., I want device arrivals of non-sliced devices to result in automatic mounts). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809202151.OAA02593>