From owner-cvs-all Fri Feb 13 14:59:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA26564 for cvs-all-outgoing; Fri, 13 Feb 1998 14:59:25 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA26099; Fri, 13 Feb 1998 14:56:06 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id OAA04891; Fri, 13 Feb 1998 14:54:45 -0800 (PST) Message-Id: <199802132254.OAA04891@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Paul Traina cc: Mike Smith , core@FreeBSD.ORG, junichi@jp.freebsd.org, committers@FreeBSD.ORG Subject: Re: wfd block major number reassignment from 24 to 1 In-reply-to: Your message of "Fri, 13 Feb 1998 14:31:18 PST." <199802132231.OAA18889@base.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Feb 1998 14:54:44 -0800 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > 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. The bootblocks already encode the slice number and pass it to the kernel: /* * For backwards compatibility, use the previously-unused adaptor * and controller bitfields to hold the slice number. */ bootdev = MAKEBOOTDEV(maj, (slice >> 4), slice & 0xf, unit, part); > 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. I understand. I still hold my line about adopting the NetBSD standalone bootstrap, but that leaves us searching for developer time. 8( Agreed on everything else you say. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message