From owner-freebsd-hackers Wed Nov 1 14:09:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA29867 for hackers-outgoing; Wed, 1 Nov 1995 14:09:14 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA29862 for ; Wed, 1 Nov 1995 14:09:11 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA00366; Wed, 1 Nov 1995 15:06:57 -0700 From: Terry Lambert Message-Id: <199511012206.PAA00366@phaeton.artisoft.com> Subject: Re: More nits To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 1 Nov 1995 15:06:57 -0700 (MST) Cc: terry@lambert.org, grog@lemis.de, hackers@FreeBSD.org In-Reply-To: <1330.815259112@time.cdrom.com> from "Jordan K. Hubbard" at Nov 1, 95 12:51:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7520 Sender: owner-hackers@FreeBSD.org Precedence: bulk > > I don't understand. You want it to mount a non-existant drive? > > It's easy to understand. > > You have a CDROM mount in your fstab. It's not using "noauto." > > 99% of the time, you have a CD in there and everything's happy. 1% of > the time you don't, and the machine falls over if it needs to reboot > unattended. This is EVIL, Terry. It's totally unnecessary for it to > do that and certain mount failures should NOT NOT NOT be counted as > "fatal" errors. Sure, if I can't mount /usr then it's a pretty fatal > condition. If I can't mount my GIFS Galore CDROM, then it's most > definitely not! Clearly if you put it in your fstab without "noauto", you thought the "GIFs Galore CDROM" was critical to your use of the system. 8-). The point is, how can the system differentiate between "/cdrom" and "/usr" failing to mount? Without "/usr", you don't have your shared libraries or libexec, and it's just as fatal. So while I agree that it should fall over more gracefully, I'd have to argue that it *should* fall over. > I know, you personally are probably running some weird system where > everything except the kernel is linked to the CDROM and it *is* > a fatal error, but we're not talking about you - we're talking about > the other 99.99% of users out there for whom this behavior is simply > a pain in the ass. I hardly see that we need to reinvent the entire > removable media subsystem in order to fix this particular nit! :-) Actually, I'm running a system where if a device is detected, it's passed to a mount, and each file system is asked if it wants the device, and if it does, then it's mounted relative to the value in the /etc/fstab, or if it's not in the /etc/fstab, it's not mounted. So the /etc/fstab is a device-name-to-mount-point mapping table which is used if a device is detected, not a list of operations that need to be performed. This means that the remount facility has to unexport the previous mount for an overlapping mount, which happens to fix the mount -a remount bug as well (it's only a feature if the behaviour is expected -- the "-a" option from a user expects to mount unmounted things in the fstab, not remount mounted ones over themselves). > > > I think you're right. Hmmm. I will have it ask you when you leave > > > the editor, 'k? What do the others think? > > > > I think the whole logical volume device mapping is going to change > > under devfs. I think it *doesn't* belong in the partitioning tool. > > Excuse me?! What does adding a boot manager have to do with logical > volume device mapping? It has to do with what the hell belongs in a partitioning tool, and writing a boot manager is one of the things that damn well doesn't. If logical partitioning is handled by fdisk, the more logical partitioning interface mechanisms you support, the more of a frob writing the MBR with fdisk becomes. It becomes a piece of crap when you port your tools to a non-DOS platform. Actually, you want an imposed heirarchy that results from iterating the device file system for the types of devices desired on a bredth-first basis. Consider: I have raw devices that map to targets and LUNs. This is the native driver presentation to the kernel. We will ignore issues of media perfection, volume spanning, and disk striping for the purposes of this discussion. We have a list of logical device drivers. We ask the logical device drivers iteratively if they want a device until they all answer "no". Consider the following set of logical devices: 1) DOS Partitioning 2) DOS Extended partitioning 3) BSD Extended partitioning (disklabel) Say we have a device "wd0". Say it has 3 DOS partition table entries: i) DOS primary partition ii) DOS Extended partition iii) FreeBSD Extended partition Say the DOS extended partition has a DOS secondary paritition on it Say the BSD Extended partition has the "slices" (stupid name) a,b,e, and f (stupid out of sequence letters) on it So we have: ,-------------------------- exported into fs namespace by devfs | ,------------------ exported into fs name space by device driver | | ,-- exported into fs name space by logical devices | | | |<---->|<------------->|<----------->| /dev devfs /wdc0 first wd controller /0 first disk on first wd controller /p1 DOS primary partition on first disk /p2 DOS extended partition on first disk /p1 DOS secondary partition on extended partition on first disk /p3 BSD extended partition on first disk /a Slice 'a' on BSD extended partition /b Slice 'b' on BSD extended partition /e Slice 'e' on BSD extended partition /f Slice 'f' on BSD extended partition Now ...how do I make an "fdisk" that can handle all this? I do it by querying the list of logical partitioning mechanisms that are available to me and presenting a map for them, as well as a mechanism for implementing an instance of them. In memory in the devfs, each of these are stored as a reference to the real physical device or the previous logical device with an offset and a length (domain + range) which the device operates on (gee, note how cleverly this allows us to collapse layers when no physical translation occurs, as well as how cleverly this allows us to prevent the layering collapse when we want to support striping, volume sets, spanning, and media perfection... note how the media perfection is useful for both disklabel and superblock contents, unlike the stupid bad144 stuff). Gee, it would be nice to put the OS dependent perititioning mechanism in to nice, logically seperate, OS dependent bundles like this so we can mount OSF and Sun and JFS disks on Alpha, SPARC, and PPC hardware. How do you tell a logically layered device from one that isn't? You call getdirentries(2) on it, and if you get an ENOTDIR, it's a terminal node. Note that there is no reason you can't open/read/write/ioctl intermediate devices: after all, in devfs, they have a vnode associated with them: the calls don't give a damn if the vnode type is VDIR or not. > Terry's off in space again!! :-) Hardly. It's Jordan who wants to jam a PC specific, single logical layer specific *wart* into the nice, clean, system independent fdisk interface that would otherwise work for AIX, SunOS, OSF/1, and other OS's so we can *FINALLY* abstract the idiotic, limited, BIOS geometry dependent DOS partition crap. The correct place to write the boot code is to /dev/wdc0/0 using some generic piece of code that dlopen's a logical device specific object module and references logical device specific data (like an MBR image, for instance). Barring doing it the correct way, it should be a seperate program that can tell the devfs to rescan the device from the affected layer up -- you need that anyway to support insertion of removable media. Please, please do not put it into a frob that will just have to be ripped right back out and made standalone again. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.