> 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 > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > >
-- Regards Vladimir 'phcoder' Serbinenko _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
