Date: Fri, 13 Feb 1998 14:31:18 -0800 From: Paul Traina <pst@juniper.net> To: Mike Smith <mike@smith.net.au> Cc: core@FreeBSD.ORG, junichi@jp.freebsd.org, committers@FreeBSD.ORG Subject: Re: wfd block major number reassignment from 24 to 1 Message-ID: <199802132231.OAA18889@base.juniper.net> In-Reply-To: Your message of "Fri, 13 Feb 1998 14:07:09 PST." <199802132207.OAA04720@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199802132207.OAA04720@dingo.cdrom.com>, Mike Smith writes: > > I intend to reassign the wfd block device to (currently unused) > > major #1 before the release of 2.2.6. While I've fixed most of > > the stupid code in the kernel that expects boot devices to be > > sequential from major #0, I cannot fix the boot blocks without a > > noticable increase in code size (I'd need to make devs a structure > > with major/minor numbers). > > Erk. > > > If you have any objection, please speak now, otherwise I'll be > > making this change ASAP. > > No, I think this should be OK. > > > Paul > > > > p.s. Just as a heads up, I've also rewritten most of the generic and driver > > code to use the new bdevsw flags, so we can remove the hard-coded majo > r > > numbers in various parts of the kernel (barf). > > Hey, while you're on this, could you look at what is involved in > actually using the slice number passed in from the bootblocks when it > comes to finding the root filesystem? ie. calculate the rootdev using > the slice minor rather than the compatability minor? That'd make > Jordan Extremely Happy. I'm looking at exactly this code right now on the kernel side. It is extremely annoying in the shipping state (2.2, I haven't looked at 3.0). I wasn't planning on adding that code to the boot code due to space considerations in the boot blocks. I hate to bitch and whine, but the reality of the situation is that boot2 is as bloated as it is because of kludges on top of kludges in the boot code. If someone actually had the time and energy to completely restructure the boot code from scratch, I think we'd be in much better shape. Unfortunately, I find myself trying to scrape yet two more kludges into the code to handle wfd style boot devices. I just don't have the time (read I'm fixing this stuff during compiles of real work) to rewrite the boot code from scratch. Right now the way boot devices are found and selected is the mess I'm trying to clean up as part of adding in bootable wfd support. There is NO good way to do this right now because you can drop a "sliced" or "non-sliced" floppy into a LS-120 drive as a boot device. I think the smartest idea would be to first insure that the diskslice code REALLY does sane things when you stick a non-sliced device in (I still don't understand that part of the code well enough to be sure it's doing the right thing, I have observational evidence it does not.) Then, once we're sure the diskslice code is robust in that situation, convert ALL bootable device drivers, (read: the fd [sic] and *cd* drivers) over to use the diskslice arrangement for minor numbers. Unfortunately, while these changes remove significant cruft from the kernel, a shift in minor numbers on the floppy driver would be somewhat catastrophic in terms of compatibility. Right now, I'm just really confounded and frustrated by the whole thing. I've kludged it by doing nasty stuff with boot -C, which was a bad kludge in the first place. :-( To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802132231.OAA18889>