> > 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
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
