Re: status grub2 port of grub-legasy map command

[Vladimir 'phcoder' Serbinenko]

> Do not waste your time doing so. There are many other functions that
> return data in DX, some of them specific to certain systems or TSRs -
> check Ralf Brown's Interrupt List [0] for a possibly very incomplete
> reference. The fuss about DS, BS, CX and DX being preserved is quite
> false,
It's meant "preserved unless otherwise stated"
> as even Wikipedia shows at [[INT 13]]: just check ah=41h, which
> returns in both BX and CX.
>
> The only semi-rational action we can take is to reverse the mapping
> _only_ if %dl still contains the mapped data we passed into the int13
> handler, but that leaves the question - how do we know that some 0x81 is
> actually the 0x81 we put there in substitution of the 0x80 the payload
> called with, and not the true result of the call?
>
Or we can maintain a list of interrupts under which we restore %dx. It
would contain only well documented BIOS interrupts and not TSR ones.
This approach will work with normal interrupts and has high chance of
working with TSR. But I don't think TSR compatibility is important.
> I have yet to find a bootsector that uses such information.
AFAIR CHS FAT32 FreeDOS sector does
> IIrc, there
> were so many buggy BIOSes out there that it was unreliable anyways: MBRs
> just check their own memory and bootsectors forget about it entirely.
> Nevertheless, this issue deserves a deeper look.
>> > 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.
> Er... AfaIk that's what chainloader and multiboot do when they cannot
> determine the boot disk.
Chainloader just fills %dl with garbage
> Regarding that "biosdrive", it would add more
> complexity to what already is a non-simple system. I'd say that either
> this mapping gets done automagically
biosdrive is necessary only when authomatic routines fail (no or wrong result)
>
> [0] http://www.ctyme.com/intr/int-13.htm
>
Thanks for a useful reference
> --
> -- Lazy, Oblivious, Recurrent Disaster -- Habbit
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko