Date: Sun, 09 Dec 2001 16:59:28 -0800 From: Peter Wemm <peter@wemm.org> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern subr_diskmbr.c Message-ID: <20011210005928.9538A3810@overcee.netplex.com.au> In-Reply-To: <200112092200.fB9M0J660085@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Joerg Wunsch wrote: > Mike Smith <msmith@FreeBSD.ORG> wrote: > > > - The MBR partition table is not "obsolete", it's a part of the PC > > architecture specification. > > Its design is antique. Or rather: it's missing a design. See other > mail for the reasons. For FreeBSD, it's obsolete since we don't need > to rely on fdisk slices. (Or rather: it's optional. We can make good > use of it when it's there, but we don't need to insist on it being > there.) No, it isn't. We specifically have a copy of both the broken and fixed fdisk tables in the kernel and do a bcmp() to see if the fdisk table that is included in /boot/boot1 **uncoditionally** is in fact the dangerously dedicated table. If it is, then we specifically reject it or we end up with a disk size of 25MB (50000 sectors). > > You do realise that "DD" mode does include a (invalid) MBR partition > > table (now valid, courtesy of a long-needed fix), right? > > Yes, of course, one that is basically ignored by everything. It has > always been there, back since 386BSD 0.1. 386BSD 0.0 didn't recognize > fdisk tables at all, but could only live on a disk by its own (as any > other BSD before used to). No, it isn't ignored, BIOS'es "know" that fdisk partitions end on cylinder boundaries, and therefore can intuit what the expected geometry is for the disk in question. It does this in order to allow the CHS int 0x13 calls to work. The problem is that the int13 code only allowed for 255 heads, and the fake "end of disk" entry that is unconditionally in /boot/boot1 specified an ending head number 255 (ie: 256 heads). When this gets put into a byte register it is truncated to zero and we get divide by zero errors. > > I'd love to never hear those invalid, unuseful, misleading opinions > > from you again. > > ETOOMANYATTRIBUTES? :-) > > As long as you keep the feature of DD mode intact, i won't argue. If > people feel like creating disks that aren't portable to another > controller, they should do. I don't like this idea. We can just as easily have bootable-DD mode with a real MBR and have freebsd start on sector #2 instead of overlapping boot1 and mbr. This costs only one sector instead of 64 sectors (a whopping 32K, I'm sure that is going to break the bank on today's disks). I'd rather that we be specific about this. If somebody wants ad2e or da2e then they should not be using *any* fdisk tables at all. Ie: block 0 should be empty. The problem is that if you put /boot/boot1 in there, then suddenly it looks like a fdisk disk and we have to have ugly magic to detect it and prevent the fake table from being used. I would prefer that the fdisk table come out of /boot/boot1 so that we dont have to have it by default, and we use fdisk to install the "DD magic table" if somebody wants to make it bootable. > But to be honest, see my other article: i never argued to make this > the default or a recommended strategy in any form. It should only > remain intact at all. Back to the subject, the current warning > however, is pointless, and has the major drawback to potentially hide > important console messages. The console buffer is 32K these days. You'd have to have around 300 disks to have any real effect on the kernel. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 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?20011210005928.9538A3810>