Is it the kernel's job to return some random number, or to return the
correct geometery?
It is the kernel's job to return the correct geometry as it would be seen by
the system BIOS. If the driver is unable to deduce this, using a geometry that
may be inferred from the partition table might be reasonable; even better still
would be returning 0/0/0 as "unknown". This will force a warning from FDISK.
Which of my four systems should I run the FDISK on? I will want to access
the same disks under DOS (which I can do with Adaptec and Qlogic since
they both use the Adaptec Extended mapping standard). This would limit me
to having to format any >1GB drive on my Qlogic at home (or now with my
laptop unless aha152x goes back to the pre 1.3.98 version). I only know
this because I have investigated it. Running the linux fdisk to create a
new linux partition anywhere else would destroy the DOS partition
Not if you correctly set the C/H/S values in FDISK. If you want Linux FDISK to
be smarter or better documented, I strongly support that idea. There's no
reason it couldn't prompt the user whenever it detects mismatched geometry
between HDIO_GETGEO and the partition table, and allow the user to select the
"incorrect" existing geometry if desired. Similarly for LILO if necessary.
That would lower the degree of "expertness" involved.
These drivers (and I checked out lots of others that simply did a cut-paste
and only do 32/64 and many truncate at 1GB) were broken in 1.2, weren't fixed
in 1.3, and are still buggy in 2.0. Which release will contain verified,
fully working drivers? 2.2? 3.0? 10.0?
Obviously I cannot answer that. But unresponsive driver authors is not a
reason to include unnecessary and ill advised code in the kernel. If you've
determined the correct implementation for a specific host adapter, submitted a
patch, and a driver author ignores you, that is a social problem and can be
dealt with. Driver bug fixes are certainly welcome, though the driver's author
should always be given an opportunity to comment upon or rewrite a fix if they
aren't happy with it.
Your solution is to have any user with problems to become experts with
lilo and fdisk, assuming they can determine if their particular driver is
broken, and figure out what the correct values actually are.
Any user facing this problem will have to acquire a certain degree of knowledge
to understand what will and will not work in a situation with mismatched
geometries. I don't see that recompiling the kernel with an EXPERIMENTAL
option that hides the genuine issues is a better solution than improvements to
FDISK (and possibly LILO) that wouldn't involve recompilation.
I didn't hold that my solution was neat or clean. I only held that it
bypassed 95% of the bad drivers (and belonged in the experimental
category).
I still don't see the need for it. The only reason geometry determination
belongs in the kernel at all is that the SCSI drivers must be consulted for
this information. I still believe that FDISK is the correct place for
improvements, not a kernel patch that can cause incorrect results to be
returned.
Leonard