Re: Replacing the legacy "map" command

["Javier Martín" <lordhabbit@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

> > For grub, i'd suggest
> > map [olddrive newdrive] ...
> > eg. map (hd1) (hd0) (hd0) (hd1)
That was the syntax used in GRUB Legacy, it was successful and could be
reused, but I'd prefer the "drivemap" command I suggested earlier, with
options not just to map drives, but also to show the mappings and to
reset them to the BIOS defaults. I'd still consider a "--automap" flag
in the "chainloader" command quite useful, but I don't know how could
this be set up, since there would be two modules involved: "chain" and
the new "map" module. Chainloader would need to check whether the "map"
module is available and/or loaded ~_~

> > The map command would just store the given parameters (converted to
> > bios hex drive numbers) to a table/array.
> > When the boot command is issued, grub would install an int 0x13
> > handler that uses this data as an lookup table
> > to convert requests and "forward" them to the original int 0x13
> > handler.
Again, that was the method used in GRUB Legacy and my original plan:
contrary to what is suggested in other posts, the mappings would not
apply immediately, but just be stored in an appropriate table. The
required ISRs would be installed only after the boot order is issued,
and the logic in grub_chainloader_real_boot.

> > By the way, I can imagine that some kernels not loaded with
> > "chainloader" may benefit from the remapping as well. 
If we want the mappings to be applied to loaders other than chain,
however, we need to make sure the function installing the ISRs is run
before grub_X_real_boot. I'm not sure if installing such a "pre-boot"
handler is possible without significantly modifying the in-place
structure of GRUB.

Cheers!
Habbit



[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]