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

[Patrick J. LoPresti]

Szakacsits Szabolcs <szaka@xxxxxxxxx> writes:

> Currently no code or a way to do this for all kernels neither in user, 
> nor in kernel space, AFAIK. 
>
> Several tools need it. 

Right, which is why putting the logic in Parted is the wrong design.

> However there are cases like empty partition table, fixing partition
> table if asked, mkntfs, ntfsck, etc when you need the bootloader
> friendly geometry what I suspect is the EDD geometry, usually. Linux
> can't do that: HDIO_GETGEO doesn't tell and no user space code that
> could be used for all kernels.

Right.  So this "smart" code has no place in Parted for two reasons:

  1) The best approach varies depending on your kernel.

  2) Parted is not the only tool which needs the Windows-compatible
     geometry.

Parted should do the simplest possible thing.  Allow the user to
specify the geometry, and default it to HDIO_GETGEO (or just
X/255/63).

> If my memory serves well, you wrote once long ago that your project
> needs the "legacy" value to make things work.
>
> Kernel 2.4 guessed usually legacy, right? 

On a blank disk, yes, I believe so.  Or it tried to parse the CMOS
tables or something.  It may have had some "infer from the partition
table" logic, too...  I never looked at it very carefully.

> Kernel 2.6 returns extended and it more upsets tools and users with
> trashed partitions.
>
> So a simple question: why is returning the extended values better
> than returning always the legacy values (or even the previous
> guess)?

Because in 2.6, the extended values are obtained by talking directly
to the IDE controller, not the BIOS.  The "raw controller" geometry
happens to match the extended geometry on every system I have seen.

The problem with having the kernel use the BIOS is complexity; in
particular, the complexity of mapping between BIOS disk numbers and
Linux devices.  This task is "impossible" in theory but quite possible
in practice, and becoming more possible all the time (as more BIOSes
support EDD 3.0).  But it is still complicated, which is why the logic
belongs in user space.

 - Pat
-
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/