Date: Fri, 13 Feb 1998 14:44:17 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Paul Traina <pst@juniper.net> Cc: Mike Smith <mike@smith.net.au>, core@FreeBSD.ORG, junichi@jp.freebsd.org, committers@FreeBSD.ORG Subject: Re: wfd block major number reassignment from 24 to 1 Message-ID: <Pine.BSF.3.95.980213144121.23295A-100000@current1.whistle.com> In-Reply-To: <199802132231.OAA18889@base.juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I know I sound like I'm bitching, but htis whole question has been addressed (and largely thrown away) with the devfs/slice code.. so far everyone who has run it has ahd no problems (including mike smith on varying hardware and simon shapiro on HUGE raid arrays. and me on almost everything in between The whole mouting root issue is addressed in a new file 1386/i386/mountroot.c the reluctance of core people to try out devfs is the only reason for it's non existance in the current tree as far as I can see. On Fri, 13 Feb 1998, Paul Traina wrote: > > 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?Pine.BSF.3.95.980213144121.23295A-100000>