Re: RFC: disk geometry via sysfs

[Phillip Susi <psusi@cfl.rr.com>]

linux-os (Dick Johnson) wrote:
> 
> You sure are interested in arguing. The translation cannot be wrong
> because the BIOS invented the translation which was created when
> the BIOS did a "read capacity." That translation is stored in the
> BIOS as a BPB, not on the disk, and it is accessed by any file-
> systems that use the 16-bit Int 0x13 interface. If the file-
> systems are not broken, they will NOT use the wrong translation
> because they will read the current interpretation by reading
> the BPB from the vector represented by int 0x64, or by executing
> Int 0x13, function code 8 (read drive parameters). These parameters
> are INVENTED upon startup as previously explained.
> 

The BPB is stored in the MBR by fdisk.  The MBR also contains CHS sector 
addresses for the location of the partitions on the disk.  fdisk 
computes those addresses by translating the LBA into CHS using a 
geometry.  If the bios is using a different geometry then those CHS 
addresses that the boot loader will request the bios to load will have a 
completely different meaning, so the loader won't get the intended sector.

> As previously explained, the fake geometry is not geometry at
> all, but rather a translation key that was decided upon
> startup after the capacity was determined. Its sole purpose
> is to get a sector-offset through the limited register-set
> in the 0x13 interface.
> 

Yes, I've been saying it is a translation key the whole time.  The bios 
uses it to figure out what sector you are referencing in int 13, and 
fdisk uses it to figure out what CHS values correspond to a given LBA so 
it can store them in the MBR.  If they don't both use the same 
translation key, they aren't both speaking the same language, and so the 
boot loader will break.

> [FS offset]--->[encode KEY]--->[INT 0x13]--->[decode KEY]--->[drive offset]
>                          |                             |
>                          |-- anything that will fit ---|
> 
> This encode/decode key should have never been let out of its cage.
> Unfortunately some DOS tools put it on the disks in a table
> called the BPB.
> 

And fdisk must also perform the encode so the partition table can 
correctly indicate where the partition begins.  The boot loader passes 
those values to the bios which decodes them.  The encode and decode must 
both be done using the same key.

> DOS creates two software interrupt vectors, int 0x25, and
> int 0x26, (absolute read and write), which perform this
> translation using the stuff in the BPB. This means that
> the caller (the file-system) doesn't have to worry about
> these things.
> 

We aren't talking about dos's filesystem here, we're talking about the 
windows ( or dos ) boot loader which directly uses int 13 and passes the 
CHS values from the MBR.  The meaning of those values is entirely 
dependent on the geometry, so when fdisk writes those values to the MBR 
it has to be using the same geometry that the bios will use to decode 
it, otherwise when the sector address of the partition is encoded using 
one geometry, and decoded using another, it will come out all wrong.

> Since the offsets are directly available when the BIOS is not
> used, this BPB is useless.
> 

The boot loader is directly using the bios.

> Even when using dosemu, where a virtual 0x13 is available, the
> key used to access this resource is obtained by reading the
> capacity of the DOS file-system(s) and building a BPB for
> each (virtual) disk.
>