From: Andre Hedrick <andre@linux-ide.org>
Andries,
I know that I promised to stay out of geo-issues, and I have......
But will you at least acknowledge that there is a need to change
what the kernel reports as far as the geometry request returns.
This is not geometry mucking, but changing to allows the kernel
to return the full 24-bit limit.
As 34.2, 37.2, 40 GB drives are becoming the standard, I must stress
the need to update the kernel/utilities combo to allow the larger
reporting. I have the 2.3.99-pre3 kernel (less scsi, just found
the issue) updated.
I need you help in recoding fdisk to allow for checking for
HDIO_GETGEO_BIG and HDIO_GETGEO. Obviously "HDIO_GETGEO_BIG" is a
transition call until the size of hd_geometry is adjusted to allow
for the larger cylinder sizes.
It is superfluous.
Already for some time cfdisk has not used HDIO_GETGEO to find
the number of cylinders. The latest fdisk does not use it either.
So, there is no reason to introduce HDIO_GETGEO_BIG.
[These days the kernel finds the number of cylinders by
dividing total capacity by (heads*sectorspertrack).
User space utilities can also do this division, and slowly
all get updated to actually do this.]
[We do not want to add more geometry stuff to the kernel.
We want to get rid of everything.]
[Unfortunately, if I am right in my guess that these jumpered
large disks require READ NATIVE MAX ADDRESS, that will
introduce new code, and new problems - there may be a
password on this SET MAX ADDRESS stuff.]
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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:17 EST