Date: Mon, 30 Oct 1995 13:23:02 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, msmith@atrad.adelaide.edu.au, hackers@freebsd.org, lenzi@cwbone.bsi.com.br, terry@lambert.org Subject: Re: boot disk.... Message-ID: <199510302023.NAA06533@phaeton.artisoft.com> In-Reply-To: <199510300839.TAA14176@godzilla.zeta.org.au> from "Bruce Evans" at Oct 30, 95 07:39:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> Drivers only need to know about the BIOS translation so that they can > >> report it to fdisk so installers can get the geometry right. This is > > >The BIOS geometries for all BIOS-recognised disks would theoretically be > >passed in in the kernel environment block. (the same techniqe would be > >used for passing in the name of the root device, any userconfig tweaks, > >the _real_ memory size as determined using the "correct" technique(s), etc.) > > 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. 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. If you had the partition table list vector associated with the device and the partition entries were in sector offsets instead of C/H/S (my previous suggestion), then you could ignore geometries for everything but the creation of partitions (Bruce's last message). If the sector offsets were on the disk itself, then the geometry could be interpolated from the sector offset to C/H/S mapping provided by the partition table contents themselves (it's a simple LCF graph reduction problem, about 36 lines of code once the numbers are known). > >> remarkably complicated, especially for handling of disks not covered > >> by the BIOS, and still not handled right. The stage 2 bootstrap > > >If the disk isn't covered by a BIOS, then there's no translation involved, > >and no need for alternative geometry to be passed in. > > You forget old MFM drives :-). The ending C/H/S hack to support these > may have to be supported forever, and it works for all drives with a > correctly initialized FreeBSD slice. fdisk should enforce it Not only that: A second AHA controller with BIOS disabled will use translation, as will an AHA secondary device that isn't bootable but has Adaptec's device= line in its config.sys. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510302023.NAA06533>