Ah, _this_ makes sense. Maybe we need two patches: one for the IDE
improvements, and one for "get BIOS info to INITSEG". Perhaps a comment in
the latter could say "HDIO_GETBIOS: don't even think about using this
without registering with Andries".
>And no, we are not able to get all the information we need
>from the IDE controller. You see, the information we talk
>about have nothing to do with the actual disk hardware -
>what fdisk and LILO would like to know is what geometry or
geometries
>the BIOS and other operating systems will invent for this hardware.
>So far they did not try to determine this themselves, but asked
>the kernel using the HDIO_GETGEO ioctl. However, this ioctl
>returns the wrong results (as you know) and it is far easier
>to let the kernel make all relevant information available to
>user space than to make the kernel decide.
I sat and stared at the code until my eyes went round in circles, and I came
to the following conclusions:
1. Getting the BIOS info with all of Andries's methods may or may not be
sensible. I suspect it will lead to screwups, because there is no way to
ask the BIOS if a disk is IDE or SCSI. But... this is Andries's problem for
fdisk, and should not be a kernel problem.
2. The kernel should not use the numbers from the various BIOS info calls
under any circumstances. If we do collect this data in setup.S, it should
be there on an "as-is" basis for fdisk and lilo. We know that this data is
just plain wrong in many cases.
3. Therefore, we should be able to remove probe_cmos_for_drives(). All this
currently does on most systems, is to initialise (thus preempting do_probe)
the CHS numbers for hda and hdb (only) with BIOS-translated geometry, which
(a) may well be completely wrong, (b) is not necessary for the kernel, and
(c) causes a drive to show different geometry in dmesg depending on whether
it's hda or hdc.
So my proposed patch to Golf is trivial: put #if 0... #endif around
probe_cmos_for_drives() (and the call to it in probe_hwif()). The setup.S
code (even the existing code, before patching) should be marked "do not use
in kernel - if you use it all, do so with extreme caution".
[Puts on flame-proof suit and waits to find out why this won't work...]
The knowledge of how various BIOSes and other OSes choose to interpret the
ATA numbers is something that (IMHO) should be in the utilities which need
to take those other systems into account, not the kernel. So let's by all
means provide Andries with the raw info he needs, but just because we're
collecting it, doesn't mean we should use it. (I'd hope that it might be
possible instead, to generate from the disk's actual geometry, a list of
plausible pseudo-geometries that other views of the disk might use.)
At that point, also, the bug on my PC which got me involved in all this
(lilo can't reconcile the BIOS geometry with the disk, because the BIOS
numbers are wrong, because /dev/sda is hd0 in setup.S) becomes... a lilo bug
(failure to take into account the actual geometry of the disk), as it should
be, not a kernel bug.
Nick Brown, Strasbourg, France (Nick(dot)Brown(at)coe(dot)int)
__________________________________________________________
email address updates : @coe.int replaces @coe.fr
for more information, http://dct.coe.int/info/emfci001.htm
__________________________________________________________
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/