If you mean the HDIO_GETBIOS ioctl which is currently in "#if 0" in
sd_ioctl.c, then I think it should go to the trash, because I think we may
be in danger of building a house of cards here. The whole ioctl can be
removed, I think (*).
- We should be able to get all the information we need from the IDE
controller
WARNING:
I have *not* submitted a kernel patch involving HDIO_GETBIOS.
I do not wish this patch to be put into the kernel.
On ftp.cwi.nl under /pub/aeb/getbios or so there are a kernel patch
and a C-program, and I ask everybody with a recent machine and a
tiny bit of spare time to make a kernel with this patch, run the
C program and mail me the results. (Together with a description
of their BIOS and disk hardware and the relevant kernel boot messages
and hdparm -i output.)
This is a data collecting phase.
At some point in the future I hope to propose a patch somewhat
in the direction of the `HDIO_GETBIOS' patch, but it involves
a rewriting of a lot of partition stuff and only fragments
exist today.
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.
So, no, the ioctl should not yet be inserted, and no again,
it is not superfluous - it is just that I am slow, and also
would like a bit more data, especially on very recent BIOSes.
Andries
-
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/