From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1K4eqH-0001Mt-8L for mharc-grub-devel@gnu.org; Fri, 06 Jun 2008 12:31:05 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K4eqG-0001M4-9s for grub-devel@gnu.org; Fri, 06 Jun 2008 12:31:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K4eqE-0001Kt-GT for grub-devel@gnu.org; Fri, 06 Jun 2008 12:31:03 -0400 Received: from [199.232.76.173] (port=39208 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K4eqE-0001Kf-9K for grub-devel@gnu.org; Fri, 06 Jun 2008 12:31:02 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:47730 helo=kirsi1.rokki.sonera.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K4eqD-0005WR-Is for grub-devel@gnu.org; Fri, 06 Jun 2008 12:31:02 -0400 Received: from [127.0.0.1] (88.193.32.97) by kirsi1.rokki.sonera.fi (8.5.014) id 483E837C006F924D for grub-devel@gnu.org; Fri, 6 Jun 2008 19:30:59 +0300 Message-ID: <48496649.6060905@nic.fi> Date: Fri, 06 Jun 2008 19:31:05 +0300 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: The development of GRUB 2 References: <1212701730.3141.25.camel@localhost> In-Reply-To: <1212701730.3141.25.camel@localhost> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: Quoted-Printable X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: [PATCH] Reimplementing the legacy "map" command X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2008 16:31:04 -0000 Javier Mart=EDn wrote: > Hi again everybody. After some hacking with the GRUB internals, I've > completed a reimplementation of the legacy "map" command that allowed > the BIOS drives to have their numbers reassigned, in order to boot OSes > whose boot code requires their installation to be located in the first > HD (BIOS drive 0x80). >=20 > This implementation gets next to the status of the command in GRUB > Legacy, with the main changes being: >=20 > * Command: now called "drivemap", attending to suggestions in this list > * UI: the less complete part of the job. The syntax is now as follows: > drivemap (hd1) 0x80 # Makes (hd1) appear as the first BIOS drive > i.e. the second argument is now any BIOS drive number instead > of another device. This change is in part due to my lack of time, > but also because others here pointed that it would be useful to > allow arbitrary mappings. If required, old syntax could be > reimplemented in short time. > * Backend: the command is now a module, but there is also code in the > several files like the machine-specific loader.S, the loader > header file and the makefiles. > * Backend: a preboot hook system has been added to the loader backend, > allowing modules to register functions to be run just before > the grub_X_real_boot function is called. The drivemap module > uses this new functionality to get its install_int13_handler > function to be called before booting the target OS without > creating chaos in GRUB itself. > * Functionality: the new module is independent of chainloader, so its > functions can be applied with any target loader. What > effects will this have, I don't know. >=20 > This patch is just a preliminary version that has been tested only in > QEMU and Bochs, not on real hardware because I'm cut off from x86 > computers from the time being (I'm running on a PPC mac now). I will be > back to town (and to my olde amd64 box) this weekend, but I wanted to > submit this so others could scrutinize it for obvious mistakes, and > maybe test it. >=20 > I've tried to respect the style rules I've seen, but please note that > this is my first patch. Cheers! Did you forgot something from this patch :) ? Anyway... Couple of comments. No chatting on the code. No commented out=20 code unless there is a really good reason for it. Try to move int13h=20 handle to module not to kernel. We do not want to put anything more to=20 kernel unless there is a really good reason to do so. +/* This is NOT a typo: we just want this "void" var in order to take its + * address with &var - used for relative addressing within the int13=20 handler */ +extern void EXPORT_VAR(grub_drivemap_int13_handler_base); Create new type for it. Or use variable type that eats that space. This=20 way you do not need this comment to confuse people. Please do not include .mk files on next patch. Abort on error?... Ok... do you go to deinit everything before that was=20 successfully installed or just give warning or ?