--pWyiEgJYm5f9v55/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

A bit old conversation but I had to comment as I know x86
bootstrapping quite well.  I hope we're just talking x86 and platforms
that want to understand x86-formatted hard disks, because this stuff
is way too brain-damaged to merit copying.  There are no written
standards on how it must be, so the only "authority" here is how fdisk
and Redmond software did things (and even that has not stayed static).
There is no MUST, only MAY and MAY NOT. ;-)

For details on how MS-DOS and other legacy systems interpreted the MBR:
http://www.ata-atapi.com/hiwtab.htm

On Wed, Jan 03, 2007 at 09:06:18PM +0000, David Laight wrote:
> It appears to be like that at first, but in fact each of the 'extended
> partitions' is only allowed to have 2 entries - one data ptn and the next
> extended one.  The data ptn is defined relative to the current 'extended
> ptn' (ie has offset 63), whereas each extended ptn is defined relative to
> the outer extended ptn.

Suffice to say that the format itself can have a number of states
whose interpretation is not intuitively obvious.  For example, you can
mark any or all partition(s) active.  You can mark any or all
partitions as extended.  Partitions can overlap.  CHS and LBA
addresses may not be equivalent (and LBA is usually ignored).  There
have been hacks for supporting partitions whos CHS cylinder numbers
are over 10 bits (set CHS to max and use LBA).  The very notion of
cylindrical coordinates in modern drives with variable-density zones
and automatic bad sector remapping is absurd.

There are some BIOS issues, which perhaps are not so irrelevant.
Basically we need to convert values for INT 13h AH=3D02h calls.  Maybe
one day they'll ditch BIOS for something more sensible (Linux-BIOS
maybe?) but until then I suppose boot loaders have little choice.

Shooting for MS-DOG compatibility is aiming very low.  If we're trying
to decide how to interpret it, let's not leave so many states
resulting in undefined behavior.  Let's support every state with
defined behavior; if other systems can't handle it, they can hardly
fault NetBSD for being better (defined as: more liberal in
interpretation, documented, fully-defined, and self-consistent).

It seems to me the limitations such as "0-1 extended partitions and
0-1 data partitions per [extended] partition table" forcing it to be a
linked-list is due to laziness on the part of Redmond boot loader
writers or perhaps to space limitations, but not any intrinsic
limitation.  If there were more than 2 entries in the extended
partition tables, they'd actually have to think about how to traverse
a tree in a deterministic manner.  That smacks of effort, apparently.
--=20
The driving force behind innovation is sublimation.
-><- <URL:http://www.subspacefield.org/~travis/>
For a good time on my UBE blacklist, email john@subspacefield.org.

--pWyiEgJYm5f9v55/
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (OpenBSD)

iQIVAwUBRcatBmQVZZEDJt9HAQIV4A//SKOVa3SO+8xU2RiYIiZcyqthxHY/KjVu
hHTDeoqoZI2hcKgXn1ijmbqziZyKJ3mZMioniLTxqqjFzK28RhBQWtXUTKDBXVnn
3sVi8unBr5IC7YU9jRdFDGZMY+Y5CjtQRq0Wm3wJ5f8q5/CL8FzMofo+5WGYT/tZ
Bm/jiTFx2saTzqs8t87AJ89+Ap9/EnGb5DbtZv46OG5i+f2uHynf9alXiDZ/g2s9
Ge/M9IHHSJYljENFPBSIR1lzNeGVW0wWx0TvyeA48dE4uXM0WsCTxkPNeS4e+Db+
QLhbo9Nd0RyOLvs1CbsH7G4zqL/JGZHnlapmAdDLus4oppuw48cT35AuUT9kLdsP
kHt7K1CIhHfK1oTPUSjnl7iQrBVpnw+M642mx7AwPxXD195NytmwdMWe3QInjqrn
r3e+ZFYhqOgLejYAQVfsrVLzNCSYn0mdCTCoyZYxQDIEYeAZxUhzjaD49NOMUIW5
BMqIbyAmNXlv7y3micOEmcX22QkopYosijych9nfhp7W7YWOO1raIeklPW2+4IRT
pRjZ9f2LRe+0cYcBqM7lIAnUGmBnovhb7vUtgoDq9nZe27kB2B7BIRjkwOWvMdtY
HCRhPbWHkdTxz/Vrp0cpoOFSV7y0LeEQ3m4spp8xX/gJlwFRrvimLzhO7/dgTtFJ
nyvkdkbwYlo=
=Laiy
-----END PGP SIGNATURE-----

--pWyiEgJYm5f9v55/--