Re: [PATCH] Reimplementing the legacy "map" command

[Javier Martín]

Ok, new version of the patch here. Followed as many of your suggestions
as I could in one day: removed unused code, put verbose, unneeded
printfs under a conditional compilation DEBUG symbol, removed the .mk
file from the patch and moved everything out of the kernel and into the
drivemap module. What I didn't do is replacing the abort_on_error bit,
mostly because I don't know that to replace it with.

Cheers! (I hope I didn't leave anything out this time)

Habbit



Huge PS:

This patch may be useful, but in its current state it's no panacea. An
important feature is still unimplemented, and I have no clue as to how
to do so without breaking modularity: replacing the "boot drive number"
passed in DL to the booted OS with its mapped version. This is not
required for the system to work, but without it it's a bit tough to get
it functional. An example, booting FreeDOS in QEMU:

Disk 0x80 - 64 MiB, 1 primary partition (FAT16), some random data
Disk 0x81 - 2 GiB, 1 primary partition (FAT32), FreeDOS installation
            with MBR, VBR and system files

(note: remember that drivemap does not affect GRUB drive numbers)

Case #1: booting without drivemap
    set root=(hd1,1)
    chainloader +1
    boot
In order to just boot FreeDOS, drivemap isn't even needed, as its loader
obeys the 0x81 passed in DL by GRUB and loads KERNEL.SYS from the right
hard disk. However, the rest of the OS expects to get its system
partition as C:, which does not happen as (hd1,1) becomes D:. We get a
"enter command shell" prompt, which is not a completely borked system
(just entering d:\command.com solves it, though it doesn't load
CONFIG.SYS or AUTOEXEC.BAT) but isn't a pleasant view either.

Case #2: booting with drivemap, simplest
    drivemap (hd1) 0x80
    chainloader (hd1,1)+1
    boot
This works fine and boots FreeDOS: I don't know what the kernel gets in
DL when the root var is not set (FF, the code seems to say), but it
boots and loads the OS fine. The problem is we've lost access to our
first disk, since C: and D: are exactly the same partition (hd1,1) and
(hd0) is nowhere.

Case #3: booting with drivemap and both disks, first try
    drivemap (hd1) 0x80
    drivemap (hd0) 0x81
    chainloader (hd1,1)+1
    boot
This doesn't work, as the kernel tries to boot from 0x81 and doesn't
find KERNEL.SYS. However, as for why does it try this, I don't know,
since it seems to be getting FF in DL.

Case #4: booting with drivemap and both disks, second try
    drivemap (hd1) 0x80
    drivemap (hd0) 0x81
    set root=(hd0)
    chainloader (hd1,1)+1
    boot
This gets us what we wont: a working system with (hd1,1)=C: and
(hd0,1)=D:. The problem is that chainloader thinks that the true root is
(hd0), so it passes 0x80 in DL (good) but no pointer to the root
partition table entry as it would if root were (hd1,1). FreeDOS seems
not to use this pointer, but an OS using it would be either querying the
wrong table (if root=(hd0,1)) or no table at all (if root=(hd0) as in
this example). Obviously, the Good Thing (tm) would be to set root to
(hd1,1) and then modify the boot_drive stored by chainloader, setting it
to the mapped number. However, as I stated before, I don't know how to
do this without breaking modularity.

drivemap.patch
Description: Text Data

signature.asc
Description: Esta parte del mensaje está firmada digitalmente