From owner-freebsd-hackers Sat Jan 21 05:23:29 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id FAA15428 for hackers-outgoing; Sat, 21 Jan 1995 05:23:29 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id FAA15422 for ; Sat, 21 Jan 1995 05:23:17 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA18979; Sun, 22 Jan 1995 00:20:18 +1100 Date: Sun, 22 Jan 1995 00:20:18 +1100 From: Bruce Evans Message-Id: <199501211320.AAA18979@godzilla.zeta.org.au> To: rgrimes@gndrsh.aac.dev.com, terry@cs.weber.edu Subject: Re: More serial console stuff... Cc: freebsd-hackers@FreeBSD.org Sender: hackers-owner@FreeBSD.org Precedence: bulk >> > > >> part = 0; >> > > >> unit = (drive & 0x7F); >> [ ... ] >The current code is broken in some respects, and the above change >also breaks some things. >The special nomenclature hd(N,p) was meant to fix some of this, >but falls short. >... >The real crux of the problem is how to map BIOS unit numbers to >rootdev/bootdev devices numbers for the kernel. The current code does >not work quite right, nor does the above proposed hack really fix the >problem. >I think we can fix this by making the way hd(X,y) works slightly >different, and using something like the above change. The hd(X,y) >device should be biased by 2 on the unit number for units >=2. The `hd' method only works for interactive boots. Changing the bias doesn't work because the BIOS uses a bias equal to the number of wd devices (it should have used something like bit 0x40 as a SCSI drive flag). For interactive boots I think the loader should ask for the BIOS drive number and the FreeBSD device name and not try to encode both in one hd number. For non-interactive boots the problem is slightly simpler (provided the unit number is not blown away) because the BIOS drive number must be assumed to be the one that was used to load the bootstrap. The loader could pass the problem of deciding the device name to the kernel by constructing an almost-unique signature for each drive supported by the BIOS. The C/H/S values would be unique in many cases. Unique data areas on the drives could probably be found for other cases. This scheme also requires the kernel to know about all drives known to the BIOS and for extra drives not to match the signatures. Bruce