Re: RFC: disk geometry via sysfs

["linux-os \(Dick Johnson\)" <linux-os@analogic.com>]

On Thu, 16 Feb 2006, Phillip Susi wrote:

> linux-os (Dick Johnson) wrote:
>> I read it, and it's wrong. You don't bother to learn. I will
>> take one last hack at this and then drop it.
>>
>> When a disk is first accessed, the BIOS reads the disk capacity.
>> That's all. This disk capacity is in 512-byte things called "sectors".
>>
> You don't bother to mention HOW it is wrong, so it appears it is you who
> fail to learn.  I will attempt once more to explain.  When you call int
> 13 and ask it for C = 3, H = 4, S = 5, exactly which sector you get
> depends very much on what the bios thinks the geometry of the disk is,
> because the bios will translate 3/4/5 into a completely different value
> before sending it to the drive.  That translation is dependent entirely
> on which fake geometry the bios chooses to report the disk has.
>
> I illustrated this translation and you simply say it is wrong.  If that
> is the case then show how.

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.

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.

[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.

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.

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

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.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5590.48 BogoMips).
Warning : 98.36% of all statistics are fiction.
_


****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

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