Re: The Linux 64 GiB Limit - was: Re: oops! Should be fdisk broken?

Guest section DW (dwguest@win.tue.nl)
Tue, 26 Jan 1999 03:10:31 +0100 (MET)


From: Michael Elizabeth Chastain <mec@shout.net>

Hi Andries,

struct hd_geometry {
unsigned char heads;
unsigned char sectors;
- unsigned short cylinders;
+ unsigned long cylinders;
unsigned long start;
};

Watch out, here comes a headache.

'struct hd_geometry' is part of the kernel interface to applications,
thanks to HDIO_GETGEO.

Yes, I realised this immediately after posting, as you will have seen.

I think that the current 'struct hd_geometry' is frozen in stone.
You will have to make 'struct hd_new_geometry' and HDIO_NEW_GETGEO.
I recommend making all the fields ints and longs while you are in
there.

Then edit all the files that implement HDIO_GETGEO. I count 20 such files.

Who uses HDIO_GETGEO? LILO, *fdisk, hdparm perhaps -
really very few programs.

What does HDIO_GETGEO? Report on the best geometry the kernel can invent
in view of disk report, CMOS, BIOS, command line, partition table.

Still, the present situation is that I know of situations where the
kernel heuristics fail.

So, this guessing mess belongs in user space, especially since
the kernel itself does not need the result.
We need to do the following:

1. Introduce ioctls that report to userspace all information
the kernel has right now. Several exist already, some have
to be introduced.
2. Write a small library that comes up with geometries.
3. Replace the HDIO_GETGEO call in all programs that use it
by library calls.
4. Remove all mention of geometries from the kernel.
A great cleanup.

Andries

P.S. I would like to hear about anything that uses HDIO_GETGEO
other than the programs I just mentioned.

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