Date: Fri, 25 Oct 2002 18:35:01 +0100 (BST) From: Mark Valentine <mark@thuvia.demon.co.uk> To: phk@critter.freebsd.dk (Poul-Henning Kamp), "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-arch@freebsd.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c Message-ID: <200210251735.g9PHZ1sT075954@dotar.thuvia.org> In-Reply-To: <mailpost.1035564344.74641@thuvia.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: phk@critter.freebsd.dk (Poul-Henning Kamp) > Date: Fri 25 Oct, 2002 > Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c write_alpha_disk.c write_i386_disk.c write_pc98_disk.c [Moved to -arch from cvs-all.] > The justification was given in ample amount 4+ years ago, but here > are the high-lights again: Thanks for this list, I think it's what some of us have been waiting to see. > 1: It confuses users. The reason why you don't hear much about > this now is that for four years we have installed systems > with consistent names by default. I'm not sure I agree with this. I've seen way too many conversations get bogged down in trying to distinguish between DOS partitions (they are not called "slices") and BSD partitions. The "compatibility" devices simplify this by abstracting to a single level of partitioning - this is currently the BSD partition table, but it doesn't have to be. As well as simplifying the i386 case, it brings disk partition names in line with other existing BSD platforms. > 2: It does not reflect what is on the disk, which adds > complexity and failure modes to our software, both userland > kernel and bootcode. This is completely the reverse of my experience. I use the "compatibility" devices to _prevent_ having to reach for the fixit floppy when the order of the partition table entries changes. The index into the table which we hard code into fstab does _not_ mirror how DOS and others use this table. The encoding of the partition table index in device names in /etc/fstab might therefore be considered a bug. It also makes it harder to dump and restore BSD partitions across disks which have and don't have an MBR partition table, or in which the 0xA5 partitions just happen to have different indexes in the table. > 3: Aliasing disk devices is a bad idea. You don't want people > to accidentally mount /dev/da0a and /dev/da0s1a at the same > time so you have to add complexity to your kernel side code > to prevent this. If this is really a problem, make the heirarchical names more obviously different (such as being in a sub-directory). > 4: /dev/da0a is the legitimate name for a disk which has _only_ > a BSD disklabel on it. It's also a perfectly good way to refer to a BSD partition within an 0xA5 partition, especially if the MBR partition table exists only to satisfy a broken BIOS, and especially when there is only one 0xA5 partition. > At typical failuremode here is: "My disk wont boot", "Right > is the FreeBSD slice active in the MBR ?", "There is no > MBR!", "Yes there is", "No there isn't!" etc etc. It seems like the job of sysinstall to warn the user if this is likely to happen (i.e. he didn't make the BSD partition bootable and didn't install booteasy). > 5: This entire thing is a bloody bikeshed! Nobody cares about > the fact that we get an Disk IO system which is multi-architecture, > modular, extensible, Giant-free etc etc, instead they focus > on the one little detail they _do_ understand, and make a lot > of noise, just to show how much they are "in the loop"! I'm sure we'll appreciate the progress you've made once we've seen what it gives us. We're simply asking why we have to sacrifice a traditional interface (and in my experience one which is more reliable) to buy into it. What is the cost of having both? Cheers, Mark. -- Mark Valentine, Thuvia Labs <mark@thuvia.co.uk> <http://www.thuvia.co.uk>; "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- <http://www.calvinandhobbes.com>; <http://www.freebsd.org>; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210251735.g9PHZ1sT075954>