From owner-freebsd-hackers Mon Oct 30 18:28:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA03592 for hackers-outgoing; Mon, 30 Oct 1995 18:28:35 -0800 Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id SAA03587 for ; Mon, 30 Oct 1995 18:28:29 -0800 Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.9/8.6.9) id MAA02851; Tue, 31 Oct 1995 12:55:59 +1030 From: Michael Smith Message-Id: <199510310225.MAA02851@genesis.atrad.adelaide.edu.au> Subject: Re: boot disk.... To: terry@lambert.org (Terry Lambert) Date: Tue, 31 Oct 1995 12:55:58 +1030 (CST) Cc: hackers@freebsd.org In-Reply-To: <199510302023.NAA06533@phaeton.artisoft.com> from "Terry Lambert" at Oct 30, 95 01:23:02 pm Content-Type: text Content-Length: 1891 Sender: owner-hackers@freebsd.org Precedence: bulk Terry Lambert stands accused of saying: > > Yes, this is already done, but it isn't used because the translation of > > BIOS drives to device numbers (soon to be names) isn't known, especially > > for specially configured SCSI devices, and the memory size is only > > correct up to 64MB. > > Exactly. There is no way (short of MD5 checksums) to map the BIOS drive > ID to the BSD device number. Nothing wrong with this. I had infact even considered a scenario where the bootstrap, if it didn't find a BSD slice where it thought one should be, would search the disk looking for it, and (if possible?) make whatever corrections might be in order. > This is because the BIOS drive ID is based on POST initialization order > and how the INT 13 is chained by the controller BIOS, and the BSD device > number is based on the controller probe order. And so forth. I'm open to reliable ideas on uniqiely identifying disks based only on ther contents. More precisely, FreeBSD slices in disks. It really wouldn't be too hard to go through the list of BIOS-found disks with FreeBSD slices and match them up with BSD-probed disks. The 'spillage' in such a situation is actually quite a serious problem also. I can't speak for W95 or NT, but OS/2 will happily talk to devices that are supported by a driver but not the BIOS. I can't say for sure whether the fdisk tools for these two write the absolute offset correctly. (Terry covered other situations where this is likely. Bummer 8( ) > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] My car has "demand start" -Terry Lambert UNIX: live FreeBSD or die! [[