From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1HzHBo-0003YK-H3 for mharc-grub-devel@gnu.org; Fri, 15 Jun 2007 15:10:32 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HzHBn-0003Y5-3J for grub-devel@gnu.org; Fri, 15 Jun 2007 15:10:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HzHBm-0003Xk-1y for grub-devel@gnu.org; Fri, 15 Jun 2007 15:10:30 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HzHBl-0003Xg-QU for grub-devel@gnu.org; Fri, 15 Jun 2007 15:10:29 -0400 Received: from m15-111.126.com ([220.181.15.111]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1HzHBk-00021x-EV for grub-devel@gnu.org; Fri, 15 Jun 2007 15:10:29 -0400 Received: from localhost (unknown [121.201.45.49]) by smtp1 (Coremail) with SMTP id wKjJCxEARU4f5HJG4F1aBw==.52776S2; Sat, 16 Jun 2007 03:10:23 +0800 (CST) Date: Sat, 16 Jun 2007 03:10:04 +0800 From: Bean To: The development of GRUB 2 Message-ID: <20070615191004.GA644@ws3.vdp.com> References: <4668259D.9090701@raulete.net> <466D6014.7090205@raulete.net> <87ps3xt6w7.fsf@xs4all.nl> <20070615184500.GA609@ws3.vdp.com> <87hcp9t5bz.fsf@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87hcp9t5bz.fsf@xs4all.nl> User-Agent: Mutt/1.5.13 (2006-08-11) X-Coremail-Antispam: 1U3Yxn0WfASr-VFAUDIcSsGvfJTRUUUjcCY02Avz4vE14v_Ww AFxVCF77xC6IxKo4kEV4ylIxAIcVC2z280aVAFwI0_Jr0_Gr1lnxkEFVAIw20F6cxK64vI FxWlx4CE17CEb7AF67AKxVWUJVWUXwCjxxvEw4Wle4C267I2x7xF54xIwI1lYx0E2Ix0cI 8IcVAFwI0_Jr0_Jr4l4x8a6c8ajcxJMcIj6I8E87Iv67AKxVWUJVW8JwAFxVCaYxvI4VCI wcAKzIAtMxkI7II2jI8vz4vEwIxGrwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UM7AC8V AFwI0_Jr0_Gr1lb4IE77IF4wAFIxvE14AKwVWUJVWUGwAqx4xG64xvF2IEw4CE5I8CrVC2 j2Wlc7Ca8VAvwVAKO7xYrVA2I41lc7Ca8VAvwVA2a4k0FcxrMxkFs20EY4vE77kJM7k0a2 IF6F4Un29KB7ZKAUJUUUUUnxnvy29KBjDU0xZFpf9x07b9iihUUUUU129KBjvJXoW7CFyU KFy3Cr1DGF1ktrW7XFb_yoW8Cr4DpasIgF93Kr4DtFWIvw129w1jqFyIvFW8Zr1UWr1Fqr y8Z3s0g3W3ZF4jgF4UuFyUWr10vr1jyr4DK343CFW5ZaD== X-detected-kernel: Linux 2.4-2.6 Subject: Re: map command for grub2 draft 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, 15 Jun 2007 19:10:31 -0000 On Fri, Jun 15, 2007 at 08:56:00PM +0200, Marco Gerards wrote: > Bean writes: > > > On Fri, Jun 15, 2007 at 08:22:16PM +0200, Marco Gerards wrote: > >> adrian15 writes: > >> > >> > adrian15 escribió: > >> >> 1st) Where to save an array? > >> >> ============================= > >> >> > >> >> If I mimic the grub legacy map command I need to save an array with the > >> >> map definitions. > >> >> > >> >> static unsigned short bios_drive_map[DRIVE_MAP_SIZE + 1]; > >> >> So that each time I call something like: > >> >> map (hd0) (hd1) > >> >> it modifies this vector. > >> >> > >> >> Any example on where should I define this vector so that I can use it > >> >> from each command ? > >> > > >> > I ask the question again. > >> > >> What is this vector supposed to do? Do you really need it outside > >> map.c? > >> > >> Can you describe the design of the map command? > > > > I happen to know something about the map command in GRUB Legacy, it works > > by hooking INT 13. > > > > It first reserves a small range of memory from the top of convensional > > memory by decreasing value at 0x413, then copy its INT 13 interrupt handler > > and the drive map to this area. Finally, it modifies the IVT table so that > > INT 13 points to the new handler. > > > > Inside the handler, it uses the drive map to translate the current drive > > stored in %dl to the real drive, then jump to the original handler. > > Right, but the problem Adrian brought up was that he though he needs > to add a vector which describes the mapping as a global. I do not see > why this is required. So I wonder what he had in mind. Yes, it doesn't need to be a global variable. > > I think the main issue here is how to hook this into GRUB 2 so that > the hook becomes effective just before booting. It can be done in a grub_map_real_boot function in kern/i386/pc/startup.S -- Bean