From owner-freebsd-current Sun Sep 20 14:52:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14917 for freebsd-current-outgoing; Sun, 20 Sep 1998 14:52:28 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14905 for ; Sun, 20 Sep 1998 14:52:20 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id OAA00624; Sun, 20 Sep 1998 14:51:53 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp01.primenet.com, id smtpd000598; Sun Sep 20 14:51:50 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id OAA02593; Sun, 20 Sep 1998 14:51:46 -0700 (MST) From: Terry Lambert Message-Id: <199809202151.OAA02593@usr04.primenet.com> Subject: Re: DEVFS & SLICE? To: peter@netplex.com.au (Peter Wemm) Date: Sun, 20 Sep 1998 21:51:45 +0000 (GMT) Cc: jkh@time.cdrom.com, freebsd@timog.prestel.co.uk, current@FreeBSD.ORG In-Reply-To: <199809201928.DAA02596@spinner.netplex.com.au> from "Peter Wemm" at Sep 21, 98 03:28:17 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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