On Sun, 22 Feb 1998, Benjamin Scott wrote:
Pascal Dornier wrote:
- DOS translates logical block address into Cylinder / Head / Sector based on BIOS parameters. This is constrained by the 10 bit limit on cylinder and 6 bit on sector number (and sector numbers start at 1, which further mucks things up).
I never really thought about it, but yeah, I guess DOS's sector numbers are a form of LBA, aren't they? Is the LBA DOS uses the same as the LBA used by IDE? How could it be, given that DOS does start sector numbers at 1. Does the BIOS provide an INT13 extension/alternative that supports LBA directly? I've never looked at this stuff this closely before. Pointers to info are also welcome. :)
No, they aren't. DOS sectors are linear within the partition. And that's it. It uses damned amount of layers: linear in the partition -[int25/26]->3D-[BIOS Int13]-->3D----[IDE,EIDE] ->linear[EIDE,SCSI] For Linux: linear -[driver]-->3D----[IDE] ->linear[EIDE,SCSI]
Moreover, BIOS in LBA mode means the following: translate DOS 3D into linear and use another set of hardware commands. Interface DOS/BIOS remains the same.
- The BIOS translates this either into another CHS
What I don't understand is: If DOS and Linux coexisting on the same system, and you have BIOS geometry translation on to support DOS, Linux still works. But Linux doesn't use the BIOS. So how does that work?
It uses either linear addresses or native drive CHS. All point of BIOS translation is to map CHS addresses provided by DOS into the real addresses.
Does Linux do the remapping instead of the BIOS? There must be a
What should it remap? Who will feed CHS addresses to Linux driver? For Linux the disk is a 1-dimensional array of sectors. For DOS it's 3-dimensional one. Both are _ordered_. And there is a real disk geometry. It's also an ordered sequence of sectors. These orderings should be the same. Everything else is irrelevant. Driver (or BIOS, in DOS case) should get a position in array (1D for Linux, 3D for DOS) and transform it into the disk's one. And vice versa. All (E)IDE disks can be addressed as 3D arrays _and_ there is a command that makes disk to say you its dimensions. New disks can be addressed as 1D arrays. Now, for DOS we need to choose some dimensions suitable for DOS (Cyl<=1024, i.e.) and make a correspondence between DOS 3D coordinates and disk 3D or 1D. The only tricky part is choosing the dimensions for DOS, for correspondence should preserve the order and disk dimensions are known. That's the work of BIOS translation. For Linux we have to make either correspondence between 1D and 1D [preserving the order!], or correspondence between 1D and 3D with known dimensions [preserving the order, again]. If we know that the order is the same for DOS and Linux we can forget (in Linux) about DOS internal pecularities. And thus forget about BIOS translation.
standard method of geometry translation if that is the case (there prolly is, I just never dug that far).
The only right thing to do is put up with this nonsense during boot, then use LBA mode.
Or possibly, one of the things we can do in this project is implement a new interface for the disk I/O, for use with advanced OSes and/or bootloaders, which supports LBA directly, cleaning things up considerably. Oh, sure, it would break some things horribly, but that's why it would be an option.
Hmm. Then you can take Linux IDE driver and put it into BIOS. Yep, it will break some things. DOS, for example. And Virus95, for it is loaded by BIOS drivers. And LILO (well, _that_ is not a problem for we have the source, but DOS & Virus...). NT will survive, for it uses its own loader. And consider the fact that BIOS access is _slow_. So Linux will still use its own driver (in regular RAM) for speed reasons. The only thing that will gain something would be LILO (rewritten, i.e.).
We might even be able to implement a better partition table format (like the BSD format). The MS partition table format is absolutely horrid at times.
Not a BIOS problem. For BIOS partitions don't exist. They are just linear chunks of disk. It's determined by OS. Even in case of DOS it is so (in MSDOS.SYS, as far as I remember). Oh, and boot loader have some reduced knowledge of these matters. Then it's a question of master boot loader. Al
I know, I know, why reinvent the wheel. Because we can, dang it, that's why! :-)
-- Ben <hawk@ttlc.net>
OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com
--- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com
Alexander Viro wrote:
No, they aren't. DOS sectors are linear within the partition.And that's it. It uses damned amount of layers: linear in the partition -[int25/26]->3D-[BIOS Int13]-->3D----[IDE,EIDE] ->linear[EIDE,SCSI] For Linux: linear -[driver]-->3D----[IDE] ->linear[EIDE,SCSI]
Okay.. yeah, I actually knew most of that, I just hadn't put it together yet (sure... :). It's worse, even, because when you use IDE drives with 3D geometry, thye are doing their own translations to the *real* physical disk geometry. Swell.
What I don't understand is: If DOS and Linux coexisting on the same system, and you have BIOS geometry translation on to support DOS, Linux still works. But Linux doesn't use the BIOS. So how does that work?
It uses either linear addresses or native drive CHS.All point of BIOS translation is to map CHS addresses provided by DOS into the real addresses.
But, the system partition table uses CHS. DOS and Linux use that same partition table. In order to figure out what's what in the partition table, Linux would need to know the method the BIOS was using to map the LBA (or native drive CHS) to the CHS geometry that the BIOS is feeding DOS, otherwise the partitions would be out of sync. Right?
Hmm. Then you can take Linux IDE driver and put it into BIOS. Yep,it will break some things. DOS, for example. And Virus95, for it is loaded by BIOS drivers. And LILO (well, _that_ is not a problem for we have the source, but DOS & Virus...). NT will survive, for it uses its own loader. And consider the fact that BIOS access is _slow_. So Linux will still use its own driver (in regular RAM) for speed reasons. The only thing that will gain something would be LILO (rewritten, i.e.).
Someone already suggested hacking/modifing DOS to use LBA or our own custom BIOS calls. I would expect most modern OSes would still use their own internal drivers, though it would be nice to not have to worry about, "Now, is my kernel file/boot partition below the latest stupid BIOS limit?".
But I mentioned it mainly as an exercise in theory. :-)
For BIOS partitions don't exist. They are just linear chunks of disk. It's determined by OS. Even in case of DOS it is so (in MSDOS.SYS, as far as I remember).
Hey, something I know. :-) Your typcial BIOS checks the floppy drive, and then the first fixed disk. The first device it finds that works has the boot sector loaded and the BIOS bootloader transfers control to it. For floppy disks, the boot sector is the OS boot sector.
For fixed disks (or anything behaving like one), the boot sector is the Master Boot Record (MBR). The MBR contains a boot loader and your primary partition table. The MBR checks the partition table for the active primary partition, and loads the boot sector from that. That is the true OS bootloader. The MBR, incidentally, is what LILO overwrites. When I first heard about LILO (years ago), I was almost scared. "A boot loader that overwrites my partition table???" :-)
One of the things I like about this is that we can finally tell the BIOS about partitions. :-)
-- Ben hawk@ttlc.net
--- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request@linkscape.net Body: un/subscribe Problems? dcinege@psychosis.com
-
Alexander Viro -
Benjamin Scott