Re: RFC: disk geometry via sysfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux