Restoring HDIO_GETGEO semantics for 2.6 (was: Re: [RFC] Restoring HDIO_GETGEO semantics)

Szakacsits Szabolcs
2004-07-05T12:15:05Z

On Sat, 3 Jul 2004, Andries Brouwer wrote:
>
> But it is true, returning 0 in all other fields would have made
> it more clear that there is no attempt to return the BIOS geometry.
> It might be a good idea to do that.

I fail to see how that would solve _now_ the _current_ serious problem
with HDIO_GETGEO.

There are three different problems.

1) 2.6 kernels made very visible that the widely used Parted, libparted,
etc are severely broken. They should be FIXED. Off-topic on linux-kernel.

2) The semantic change of HDIO_GETGEO severely broke widely used, critical
tools. This issue should be HANDLED, preferable as soon as possible.
The original thread was supposed to be only about this issue.

3) There are cases when tools need to invent, not-to-be-discussed-now,
geometry for different kind of purposes. This should be IMPLEMENTED.

The HDIO_GETGEO facts we have are

- the new HDIO_GETGEO code seriously broke backward compatibility

- the old HDIO_GETGEO code still exists, just the values are thrown
away, as Andries wrote recently

- nobody could point out any _technical_ benefit why the new HDIO_GETGEO
code is better than the old one (the _way_ Andries wanted to push the
code to user space was quite "unlucky")

- nobody complained if anything would break if HDIO_GETGEO were restored

- returning 0 values have an unpredictable impact. Hence perhaps the
change shouldn't be done in the 2.6 kernels to avoid yet another
brown paper bag.

Considering all the above points, it seems logical from practical point
of view, that the restoration of the old HDIO_GETGEO functionality (or
something that's very close to its behaviour) _temporarily_ for 2.6
kernels makes sense.

Of course this wouldn't mean to be as a fix for the above 1) and 3)
problems. It's the restoration of the user space compatibility _and_
preparation for appropriate HDIO_GETGEO removal.

Szaka