Andries.Brouwer@cwi.nl wrote:
> So all that matters to me is that the geometry on the software side,
> no matter what operating system, needs to be the same.
>
> Does Windows determine the geometry from the partition table ONLY?
>
> It can use: (i) the disk, (ii) the BIOS setup, (iii) the partition table.
> In a Linux context ingredient (ii) is unavailable.
Yep. Do you know what DOS/Windows actually use?
Know? No. But in the ancient times one could not ask the disk,
so ingredient (i) was missing, and the disk really had a definite
geometry that one used to access it. The user had to specify things
in the CMOS setup. So, DOS can hardly use anything else but CMOS.
With Windows things are less simple. It knows about disk translation
schemes, and has new partition types indicating that extd int 13 is
used and geometry is meaningless.
> If that's the case, then there's no problem - we can use any geometry we
> like, by writing it to the partition table (because Windows assumes each
> partition ends on the end of a cylinder,
>
> I consider that a common myth. What are your sources, or experiments?
> I did some experiments four years ago and found this false for DOS.
> This is also false for Windows NT on an Alpha.
I didn't assert this - I have no idea if it's true. But DOS fdisk
always creates partitions according to these rules, so it is reasonable
to determine the geometry DOS is using from this, but its not reasonable
to write out a new geometry, expecting DOS to use it. Correct?
If you know that no other fdisk-type program than DOS FDISK
has ever touched the partition table, then probably partitions
end at cylinder boundaries. But if for example Linux or SCO software
has created partitions then there is no guarantee for this to be true.
And even if only DOS FDISK has been used but the disk was moved
between computers, or within one computer between SCSI controllers,
it may be false.
It seems the hard disk's actual geometry, and the geometry as DOS
sees it are two different things.
There is no actual geometry.
A program that wants to be compatible with DOS should then use
the geometry as DOS sees it, which is in turn the same as the
BIOS sees it (correct?).
I suppose so, yes.
In this case, the said program should use BIOS to determine
the geometry. Correct?
Yes, if possible. But in a Linux context you'll find that most
disks are unknown to the BIOS - many people only put their boot
disk in the BIOS setup.
But it's near impossible to call BIOS from user-space. OK, it can
be done - setting up a virtual machine like dos-emu...but this is
ridiculous for a partition program.
Methinks there should be some interface for getting the geometry
as DOS sees it from the linux kernel with some ugly ioctl, or
something. I know this is a Bad Thing TM, but are there any
other alternatives?
I made this ioctl and collected the BIOS information about a year ago.
See ftp://ftp.cwi.nl/pub/aeb/getbios/getbiosdrivedata.c and the kernel
patch in that same directory.
You can study the patch and what it produces. I am interested in seeing
more output, in case you try this on a handful of different BIOSes.
The objections remain: (i) Many disks are not found in the BIOS setup.
So the BIOS tells you nothing. (ii) It seems impossible in general
to correlate the BIOS disk numbering with the Linux disk numbering.
One could at boot time let the BIOS read each of the disks and
compute a md5 checksum of the first 100 blocks of each disk, and
afterwards let Linux read the disks and compute md5 checksums,
and compare. For the disks that occur in the BIOS setup this should
give a correlation with high confidence.
But I have a much simpler solution for you.
Assume that all disks always have 63 sectors/track and 255 heads.
Your program will work well on all modern hardware.
Or ask the Linux kernel for the geometry. It gives reasonable
answers. You complained that these are not `right', but right
is not well-defined, and they are in most cases right enough
to enable LILO to boot.
Or guess a geometry from the partition table.
Or let a user specify the desired geometry explicitly.
Geometry is a problem of the past. It does not exist anymore.
DOS does not exist anymore. People use 25 GB disks where DOS
can only use 500 MB without translations and 8 GB with translations.
If it were easy to be perfectly DOS-compatible, yes, that would be
good to achieve. But now that it turns out to be almost impossible
it doesnt really matter much. And it is easy to achieve DOS
compatibility in 95% of the cases.
In fact not only is geometry a thing of the past - the DOS-type
partition table is going to die soon. Another reason not to waste
too much time on the fact that one needs to invent some geometry
in order to fill certain fields in a DOS-type partition table.
Andries
-
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/