On Sun, 26 Mar 2000 Andries.Brouwer@cwi.nl wrote:
> It is superfluous.
I disagree strongly......
> 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.
Why duplicate the calculations?
Why not use the "TRUE" values as determined by the Kernel......
I remember you eating my shorts over this very point in the past when you
took me to school over the geometry issues!
> [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.]
Yes, and let the kernel dictate to USER-SPACE that which is kernel
knowledge..........
> [We do not want to add more geometry stuff to the kernel.
> We want to get rid of everything.]
I agree, but you have to introduce new temperary code that gives current
correct reporting of data, before we do the steps below.
> [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.]
No, but you do write to the NV ram on the drive interface that does not
get changed even of if the power is cycled.
I am working with Quantum and Maxtor on the very issue........
Since I get demo drives........If I destroy a drive, I get a new one as a
replacement..........if a generic user NUKES a drive......they are out of
a few hundred bucks..........
18 months ago you and I bucked heads over the
"READ NATIVE MAX ADDRESS" / "SET MAX ADDRESS" combination........
I was/still afraid of dropping this on the masses.........
That is why I designed the elaborate geometry mess to perform a FAKE call
of "READ NATIVE MAX ADDRESS" / "SET MAX ADDRESS".........
We have already increased the reporting capacity of
"/proc/ide/idex/hdx/geometry" to allow for 137GB limit.
Prove to me against this change that reported kernel values should not
return the same........
Round 2: DING ;-)
Andre Hedrick
The Linux ATA/IDE guy
-
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:18 EST