[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Replacing the legacy "map" command

From: Vesa Jääskeläinen
Subject: Re: Replacing the legacy "map" command
Date: Tue, 27 May 2008 19:04:19 +0300
User-agent: Thunderbird (Windows/20080421)

Hi Javier,


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.

Vesa Jääskeläinen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]