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

[Bartlomiej Zolnierkiewicz]

On Monday 05 of July 2004 23:08, Andries Brouwer wrote:
> On Mon, Jul 05, 2004 at 09:05:05PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > Andries, the question was "What should we do with HDIO_GETGEO breakage?"
> > not "Why does somebody need the BIOS geometry?". :-)
> >
> > We can fix HDIO_GETGEO to behave like in 2.4 or remove it (preferable),
> > current situation is bad.
>
> I don't know precisely why.
>
> Neither of your two proposed actions appeals to me.
>
> Here is an ioctl, and it is used for legitimate purposes
> (finding the starting offset of a partition).

It is also _abused_ for less legitimate purposes.

> You cannot remove it. We can think again in 2.7.
> For now, leave the kernel interface constant.

We can at least consider adding BLKPARTSTART and deprecating
HDIO_GETGEO so people at least will know that they should upgrade.

> Is there any advantage in going back? I don't think so.
> The old situation was broken. People lost all data.

According to szaka the "the new situation" is similar. :(

> Also "the old situation" is badly defined. The returned value differs
> for 2.0, 2.2, 2.4, 2.6.

This is just sick: same ioctl - different returned values.
Please never ever do it again - we can avoid such problems in future.

> No. We must go forward.

Yep, 2.7.1 should remove HDIO_GETGEO.
We should have done this in 2.5, really.

> Now distributions can take care of themselves. They can patch the kernel
> as they like, or patch parted as they like, or do any number of other
> things. RedHat and SuSE can take their own decisions. With some luck there
> is a new parted next week or so that they could offer.

What about people running old parted and new vanilla kernels?

> So we can go slowly and quietly, investigate precisely what happens, and
> why and how such things can be fixed. I think I understand rather well what
> is (was) wrong with parted. Maybe Szaka can teach me about other tools that
> are broken. I am confident that we can fix them, maybe in hours rather than
> days.

What about people using old versions of these tools (if any).

What I'm only worried is that there might be cases when 2.4 worked
and 2.6 doesn't which with combination with bugs in the tools cause
"where is my data?" issue.

> As a side result we will have something valuable, namely standard software
> that tries to handle BIOS data. Several orders of magnitude more reliable
> than our old guesses.

Yep.

Bartlomiej

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/