logo       

Re: Restoring HDIO_GETGEO semantics for 2.6 (was: Re: [RFC] Restoring HDIO_: msg#00060

gnu.parted.bugs

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

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).
You cannot remove it. We can think again in 2.7.
For now, leave the kernel interface constant.

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

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

No. We must go forward.

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.

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.

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.

Andries


<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise