Re: status grub2 port of grub-legasy map command

[Vladimir 'phcoder' Serbinenko]

2009/5/31 Javier Martín <address@hidden>:
> El dom, 31-05-2009 a las 13:36 +0200, Vladimir 'phcoder' Serbinenko
> escribió:
>> 2009/5/31 Javier Martín <address@hidden>:
>> > El sáb, 30-05-2009 a las 17:28 +0200, Vladimir 'phcoder' Serbinenko
>> > escribió:
>> > Put it that way, I agree with your change. To the scrapper with
>> > parse_biosdisk then!
>> Sorry, I didn't mean to upset you. Here is a patch to do it
> You did not upset me at all! I'm sorry if I seemed rude or hostile. I
> truly meant to give you a go-ahead at scrapping that code.
Ok, thanks
>>
>> Doing some tests I discovered that freedos MBR (but not the
>> bootsector) relies on %dl being preserved across int 0x13. In the
>> patch you can see additional hassle to preserve %dx.
> Do not do this. Some BIOS functions (like ah=08h) return data in dl.
> Clients should not expect data in registers to be preserved across
> interrupt calls. I don't know if there is something like a 8086/PC-BIOS
> ABI document that we can find to confirm the non-preservation of dl, but
> the FreeDOS MBR should be fixed then.
Thank you for pointing ah=8 function
AFAIK there is no normative reference. The source which was mainly
used for long years is helppc and it states following:
        - registers DS, BX, CX and DX are preserved
(http://heim.ifi.uio.no/~stanisls/helppc/int_13.html)
But now this reference is terribly outdated.
SeaBIOS preserves %dl too
According to wikipedia ah=8 is the only function which returns in %dl.
I will write an updated version which restores %dx only if ah!=8
> I managed to get the right %dl passed with the following procedure:
> let's say I want to boot FreeDOS on hd1, but I will drivemap it so that
> it will become hd0. Instead of doing this:
> root=(hd1,1)
> drivemap -s (hd0) (hd1)
> chainloader +1
> I do the following:
> root=(hd0)
> drivemap -s (hd0) (hd1)
> chainloader (hd1,1)+1
> This gets the right number into %dl (I have not checked multiboot), but
> I acknowledge that it's nothing more than a hack.
And it sets es:di (pointer to partition table entry) to incorrect value
> I cannot see a way for
> drivemap to access that data and modify it according to the mappings
> without breaking modularity with multiboot and chainloader
I think of something like having a function pointer in kernel
int (*grub_get_biosdisk) (grub_device_t dev) = grub_get_biosdisk_basic;
static int grub_get_biosdisk_basic (grub_device_t dev)
{
    if (! dev)
      return 0xff;
    if (! dev->disk)
      return 0xff;
    if (! dev->disk->dev)
      return 0xff;
    if (dev->disk->dev->id != GRUB_DISK_DEVICE_BIOSDISK_ID)
      return 0xff;
    return (int) dev->disk->id;
}
Which can be easily overridden by drivemap
But I don't really like this approach
> (and what
> about other loaders?).
AFAIR only multiboot and chainloader pass bios drive number to
payload. Other payloads are designed to use their own drivers
(multiboot is designed for both possibilities).
>
> Regarding grub2 using its own drivers, we have no reliable way of
> conclusively saying that (ata2)==(hd1), so we'd better say nothing at
> all and keep dl=ffh as we do currently.
I thought of introducing a variable "biosdrive" and doing something like
root=ata1
biosdrive=0x81
chainloader +1
boot
Setting %dl to 0xff if drive can't be determined reliably and isn't
supplied by user is a good possibility. I'll do so.
>
> --
> -- Lazy, Oblivious, Recurrent Disaster -- Habbit
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko