Re: [RFC] Restoring HDIO_GETGEO semantics (was: Re: workaround for BIOS / CHS stuff)

[Patrick J. LoPresti]

Andrew Clausen <address@hidden> writes:

> On Sat, Jul 03, 2004 at 10:15:47AM -0400, Patrick J. LoPresti wrote:
> > Parted is primarily a component of larger systems; namely, the
> > RedHat/Suse/etc. installers.  Those larger systems can figure out the
> > correct geometry (using whatever logic/heuristics/knowledge they have)
> > and pass it to the tools which need it, of which Parted is just one.
> 
> Why should they bother?  Shouldn't libparted just do it all for
> them?  (Shouldn't parted use EDD?)

Two reasons:

  1) "...of which Parted is just one."  Whatever logic you fancy for
     determining the geometry, the results need to be available to
     several tools.  Parted is only one such tool; ergo, the logic
     belongs OUTSIDE of it.  Parted should expect to be TOLD the
     geometry in any situation where it matters.

  2) The ideal logic varies depending on the capabilities of your
     kernel.  The distribution vendor knows the capabilities of its
     kernel, and can construct appropriate logic.  Putting logic into
     Parted to handle every possible kernel is a sloppy design.

I hate "smart" software.  Don't be smart; be simple.  Default to
whatever you like, but give me a way to TELL Parted the geometry.

> I was under the impression that 2.6 provides a mechanism for setting
> the HDIO_GETGEO thingy... so any program can tell Parted (and
> everything else, for that matter) what they want the geometry to be.
>
> Perhaps I misunderstood your email:
> 
>       http://www.uwsg.iu.edu/hypermail/linux/kernel/0404.0/0270.html

You understood correctly, but see below...

> It contains this:
> 
>       echo "bios_cyl:C bios_head:H bios_sect:S" > /proc/ide/hda/settings
> 
> Isn't the kernel the right place for this kind of communication to
> be happening, anyway?

Not according to the kernel developers.  They are threatening to
remove HDIO_GETGEO completely.

> > (Note that this would also provide a way for end users to fix their
> > partition tables if/when they broke.  Right now, the stock solution
> > for disks which Parted "broke" is "sfdisk -d | sfdisk -C# -H# -S#".
> > Wouldn't it be nice if people could use Parted instead?)
> 
> They can, right?  Just type the above, and then do some dummy thing
> in parted.  (Parted doesn't have a "touch" command).

No, because Parted will "helpfully" infer the geometry from the
existing partition table, no matter what HDIO_GETGEO returns!

In short, the /proc/ide/hdX/settings + HDIO_GETGEO solution 1) only
works on blank drives and 2) uses an interface which the kernel
developers consider a crock.

> > IBM Thinkpads use x/240/63.  In theory, other BIOSes could use
> > anything.
> 
> Do they break on x/255/63?

Yes, absolutely.  This is why I wrote the legacy_* support for the
edd.o module in the first place.  Otherwise, I could have used
x/255/63 and been done with it.

 - Pat