Re: Replacing the legacy "map" command

[Vesa Jääskeläinen]

Hi Javier,

Welcome!

Javier Martín wrote:
> This message is mainly concerned with "how should I implement it"?
> Since this functionality is AFAIK exclusive to the x86/amd64 PC-BIOS
> target, it should be confined there, but there are at least two paths
> of action that I can think of:
>  1.- Given that only the chain OS loader makes use of such a switch, I
> could add it as an option to the "chainloader" command. This is the
> simplest path, as it would only require modifying
> loader/i386/pc/chainloader* and kern/i386/pc/startup.S (where
> grub_chainloader_real_boot resides). Such an option would most
> probably be named something like "mapdrivefirst", as in "chainloader
> --mapdrivefirst (hd1)+1".

Do not got to this route.

>  2.- The other option would be to add a new command that managed the
> BIOS drive mappings (like, "biosdrivesmap", duh), with three main
> options: "show", "map" and "reset". I'm still unsure of what files
> should be modified for this change, and this might be overkill.
> No matter how the UI (the commands) actually ends up, the mappings
> would just be stored in a variable, and not applied until the "boot"
> command is issued. Thus, actual functionality should probably be
> implemented in grub_chainloader_real_boot, and the logic is pretty
> simple, with most of it available in the GRUB Legacy code.

Well what we actually want is to have support to install interrup 
service chains for real mode. There are couple of users for this 
service, one of them being drive mapping (to int 13h) and then El Torito 
support (to int 13h).

So you would have function to install interrupt chain and this would be 
installed right away, or at point when you are leaving grub. You may 
want to have those services even if you are not chainloading. In example 
you have multiboot capable kernel, but you want to still use BIOS services.

In case of drive mapping it would work in user interface in same way as 
in GRUB Legacy. But what happens under the hood:

1. You load drive mapping module (map.mod?)
2. User configures mapping with map command (or similar)
3. If even one map command is issued this installs custom software 
interrupt handler to tweak int13h requests. Map command data is 
installed to this handler.

Thanks,
Vesa Jääskeläinen