From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1K170e-00057Q-R8 for mharc-grub-devel@gnu.org; Tue, 27 May 2008 17:47:08 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K170d-00057F-0L for grub-devel@gnu.org; Tue, 27 May 2008 17:47:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K170b-00056u-8w for grub-devel@gnu.org; Tue, 27 May 2008 17:47:06 -0400 Received: from [199.232.76.173] (port=51415 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K170b-00056p-1u for grub-devel@gnu.org; Tue, 27 May 2008 17:47:05 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]:25271) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K170a-0008Ac-IW for grub-devel@gnu.org; Tue, 27 May 2008 17:47:04 -0400 Received: by ug-out-1314.google.com with SMTP id l31so453506ugc.48 for ; Tue, 27 May 2008 14:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; bh=Vbb0uQDTBXeoI72zp6HkAq+bSU/kUMBOBH6fIGd62tg=; b=gqgeOVnE5N2gnurzCn9mMJriVOlIRemhg4jyL19sXasNJPPSdIfRuoAZRznoFiJ32MxLEq4UZchYZ/p5DZ/e9G5pD0LJRfyw3jeOeXIhOnRfoCg+7wNybagd8Hw29Yfls3UAVg6ibxoAp9w9alXuJgvpyvIuCmUBlPS33a8B1ag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; b=UOPmfLtw8r1bHKCcv4o8e7uStjPJPr3O4Kk2hRk1n+hDnpGYaVMTTHiIyNZDaOd1GSvApi5RDDPswfsF/i84LL6Y8s7Kze+uG7AyV4r0FMKiVZuNEuabF9XSsZWMicTrpd+Kt+TJaaQEa6Ai4PWrAVBBa4pjfnwZLW/F/3+CBKw= Received: by 10.66.239.16 with SMTP id m16mr4757578ugh.28.1211924822424; Tue, 27 May 2008 14:47:02 -0700 (PDT) Received: from ?192.168.1.102? ( [82.158.23.109]) by mx.google.com with ESMTPS id q9sm23769580gve.5.2008.05.27.14.47.00 (version=SSLv3 cipher=RC4-MD5); Tue, 27 May 2008 14:47:01 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: grub-devel@gnu.org In-Reply-To: <483c317b.0c1e640a.2bd9.7c7eSMTPIN_ADDED@mx.google.com> References: <483c317b.0c1e640a.2bd9.7c7eSMTPIN_ADDED@mx.google.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-P8y2C6WFrQzBEiwqKJ97" Date: Tue, 27 May 2008 23:47:02 +0200 Message-Id: <1211924822.1372.25.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) Subject: Re: Replacing 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: Tue, 27 May 2008 21:47:07 -0000 --=-P8y2C6WFrQzBEiwqKJ97 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > 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 =EF=BB=BFgrub_chainloader_real_boot. =EF=BB=BF > > By the way, I can imagine that some kernels not loaded with > > "chainloader" may benefit from the remapping as well.=20 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 --=-P8y2C6WFrQzBEiwqKJ97 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQIVAwUASDyBVaSl+Fbdeo72AQLStA/+N+8Ygc/pyYUMkeRmw3uQFOVDNaBzSyeo ndNRZOkalRUcKauby7zUYQFnPGxmR1YbjWCTnj3E+vfgXMr7jKhZA/RsVz7TNDAO cntMjM9GSLJ3nYH9gLAS0MMFP0RQ9f6KOKRimzvOHbMyr00RjR2vhetaGV+A2G8G /6TvCeCbQAi3GKsTjx654d0dYxjxcpJfRpWxWubSfDJsShzPZr39nglvjrE+Kixb YbUU6rvGJbcgZ21YVfgGrgMUm6c25MYP2vCBl/VWRusH2xZkbl2pxjFgeJ5D1IYz fnglpJXFNItHpzVyixc604nqwCgxZQWku6OkpTz5RTyKGLo/R9eBKvNZVWmcyxPK ergP4MQ5/qutgVjRzvt+XuqeQke6qeYedfzp+hM9Q+QcaKkmF62rGcgv3N3Vwvsx MwJw6KHU8YsHMUoorcG3QqiL60wya/oAkji+sY1V4fvvwUo9mf3AxyPiOrGLWfe0 y40yyuWVmQW1ybNHxU7ExIKrHohNI0lnG2YzFltyPhffRg47nBOQQ3IjS2kt6b2C EqWCghwy5rp9XHbMtr1d4VmL1t7AxjMMJyGiyItBOaiwzJqTbEDEatKYSWaRxBqx vEW955LXk8+xhtFA5btAiAhS/zBlPeQnlGULR6I+UoHdqvIH9YfiWssl/E88cbu0 azIHUJntkqY= =/dJz -----END PGP SIGNATURE----- --=-P8y2C6WFrQzBEiwqKJ97--