From andre@linux-ide.org Mon Mar 27 00:39:16 2000
> It is superfluous.
I disagree strongly......
Look at the cfdisk source. HDIO_GETGEO occurs only in one place.
This single place reads:
-------------------------------------------
void get_kernel_geometry(void)
{
#ifdef HDIO_GETGEO
struct hd_geometry geometry;
if (!ioctl(fd, HDIO_GETGEO, &geometry)) {
kern_heads = geometry.heads;
kern_sectors = geometry.sectors;
}
#endif
}
-------------------------------------------
You see? The field geometry.cylinders is never used.
So, to cfdisk a HDIO_GETBIGGEO would not make a difference.
(And if HDIO_GETGEO is removed altogether, cfdisk
will still work fine. You see, I want to eliminate
all that reminds of disk geometry.)
> [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 if the power is cycled.
Ha! I just did these things this afternoon.
A reboot doesnt reset things, but a power cycle does,
at least as long as one does not set VV to 1.
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:18 EST