Date: Sat, 23 Mar 1996 16:12:55 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dave@kachina.jetcafe.org (Dave Hayes) Cc: j@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a damn 2nd disk Message-ID: <199603232312.QAA08450@phaeton.artisoft.com> In-Reply-To: <199603231944.LAA12669@kachina.jetcafe.org> from "Dave Hayes" at Mar 23, 96 11:44:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >Andreas was wrong here. Fdisk needs the geometry the BIOS is using -- > >not the geometry the disk claims to be. (The latter is largely > >irrelevant, that's why it's hidden by default. Anyways, it cannot be > >expressed in plain C/H/S for any modern disk.) > > Given the nature of the dissention about what this geometry really > means, isn't there a sufficiently powerful abstraction one can use > to represent the information that fdisk and disklabel need...one > that covers all drives? > > If you have that, writing any user inferface is MUCH easier. Windows 95 converts from BIOS to protected mode drivers during the boot process (to the point of causing conversion of open file handles for TSR's loaded in real mode to carry over). Conceptually, it requires alot of BIOS information to be accumulated by the boot code for use in identifying the protected mode devices BIOS equivalent drive assignments (which are not documented or stored anywhere -- they are an artifact of PSOT). You have the choice of implementing a real mode boot (/boot has been proposed) and moving the change to protected mode out of the second stage boot and into the boot program as the last thing before it starts executing kernel code... or implementing a virtual machine. 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?199603232312.QAA08450>