From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1K4xx0-0005d1-77 for mharc-grub-devel@gnu.org; Sat, 07 Jun 2008 08:55:18 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K4xwy-0005cw-Bl for grub-devel@gnu.org; Sat, 07 Jun 2008 08:55:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K4xwv-0005ck-Mr for grub-devel@gnu.org; Sat, 07 Jun 2008 08:55:15 -0400 Received: from [199.232.76.173] (port=43002 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K4xwv-0005ch-I2 for grub-devel@gnu.org; Sat, 07 Jun 2008 08:55:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]:34615) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K4xwu-00022K-WE for grub-devel@gnu.org; Sat, 07 Jun 2008 08:55:13 -0400 Received: by ug-out-1314.google.com with SMTP id l31so866330ugc.48 for ; Sat, 07 Jun 2008 05:55:11 -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=hJf08wKnVg5+muh2+lmRTxujMXFDhL/eGtKv07cBLbA=; b=GWgSR/+fNN8VBcy5V/BSz8nGEtx0bOajcAkybxD+1XCyJ7W4C5RwztWkUfVwrj/nc8 8jMhawbfXsAtELn3jwdxkz1UySwRCtQNu/4mmKvOmgGq5LtFMqb77YSIxoEWSTjqMvpF CA4gQ5LPFvBNZC32S+cRaCg3hw4QDj2wcsbXI= 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=j4vWWTwHEjr7KL9xjC9nAxJApHsOHs2hXUnNnt3Ny6BGSQuQtXLs7difd59pEAp+81 7lIn+uV241+F2g/+E0TRm4xe0kkY5AWp5TzRnW1J0HF+oe31mEspirF5tOZEVD5VlMc7 1aJ0HncsdDzB1e3ZbmYfWFaFTVfa/o3uOlgPU= Received: by 10.67.24.18 with SMTP id b18mr401228ugj.18.1212843310998; Sat, 07 Jun 2008 05:55:10 -0700 (PDT) Received: from ?192.168.1.101? ( [213.37.137.93]) by mx.google.com with ESMTPS id 31sm1465357ugg.25.2008.06.07.05.55.09 (version=SSLv3 cipher=RC4-MD5); Sat, 07 Jun 2008 05:55:09 -0700 (PDT) From: Javier =?ISO-8859-1?Q?Mart=EDn?= To: The development of GRUB 2 In-Reply-To: <48496649.6060905@nic.fi> References: <1212701730.3141.25.camel@localhost> <48496649.6060905@nic.fi> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5zbMBhTHEEOqToivqcsV" Date: Sat, 07 Jun 2008 14:55:37 +0200 Message-Id: <1212843337.13883.20.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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: Sat, 07 Jun 2008 12:55:17 -0000 --=-5zbMBhTHEEOqToivqcsV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable El vie, 06-06-2008 a las 19:31 +0300, Vesa J=C3=A4=C3=A4skel=C3=A4inen escr= ibi=C3=B3: > Did you forgot something from this patch :) ? Er... not that I know of. What do you mean? Did I leave something important off? If it's the licensing info, I put it under the same as the whole GRUB2 project, I suppose. The int13 handler code, however, is based (though changed) on the equivalent code in GRUB legacy. > No commented out code unless there is a really good reason for it. Ok, I'll remove the "debug" sections in the int13 handler. Should I also remove the non-error text output of the command? (like "mapping (hd1) to 0x80") > Try to move int13h handle to module not to kernel. We do not want to put > anything more to kernel unless there is a really good reason to do so. Seems A Good Thing (tm). However, all the loaders have their assembler code in the kernel, and I have yet to find a single assembly file out of the /kern dir (except for the setjmp.S support routines). As I state below, I don't understand the GRUB build system quite well, and would appreciate to have it explained so that I can break the asm part off the kernel loader.S and into its own drivemap.S file. > +/* 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); >=20 > 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. Well, seems the comment was not as effective as I thought ^.^ - there is _no_ space, the only purpose of that pseudo-variable is having its address taken with the & operator. The only sensible "new type" for it would be something akin to=20 typedef void grub_symbol_t; Which would be also puzzling and require a comment to stop people from changing it to void*. However, the information would be more centralized then and it would cause less head-scratching. > Please do not include .mk files on next patch. I don't quite understand the GRUB2 build system right now, but if .mk files don't get patched, how does it know they exist? Are those files autogenerated somehow? I didn't find the autotools files... > Abort on error?... Ok... do you go to deinit everything before that was=20 > successfully installed or just give warning or ? I don't know; either choice might be sensible and still has drawbacks (increased complexity, potentially undoable actions, etc). My design of this new functionality was a bit ad-hoc, and I added that flag thinking "if the drives cannot be mapped, then the user wouldn't want the system started". However, as you reason, with multiple preboot hooks the system could be let in a potentially inconsistent state. --=-5zbMBhTHEEOqToivqcsV 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) iQIVAwUASEqFSaSl+Fbdeo72AQJReA/+JpBGLM4U6YRwL8jgnPIffAiri/Kv45US ddX01VGRGz5jSONgvxKMYmgPFu3n209MAyRLe+6m8z1CoYNoCjS0Pe/wS9Rn+NII uOnFY5I8cYPaKPi6htssNmtGdPCaAj8dd74X7FtS1qr3tAto8vPou1yv3Vtto2Hv Mv6X09hNisuuOKLeAHnjUqOW98TDl1TYkovDM1LSlKE0vtjR1UlflWvbPDXWgsPQ WonRwGRgAW9mTzVLJfF7OrtRZvRjQwjyOZzaMT+944zqPfh6p499NguaBuz9MEfo YWHJa06yOMNccIxpN6oTMebv6bPRyzsgreEqG3JnuGTDnKzQDCxpvj6cMe4Mf4yM ggetWwuEdHKsJNfRlrm0bgbLgeTr+x9egJzUrfnGQg7CFRaB9Xkm0mqH9b1aCdB1 dGIZUG7fdO38dOeGRquAdO12HMNocw7xE6Y7tnhSi7E5utJ5wmdoANPPKakx3n6Y pRW6DymRA+NDA+Qo8ViLx1UpBuXvtEWOlFittNGvX6VwZSh4IObso59fD4GypiGr Cgq5osAEd7Uyss5MZOcInE2Z3c73sbQon35sVhf3NK3il/vdFPrJorYkvK+KeIQp JCwIKBlpyIata6Va8oUrfSeXfZF6LHax2L9C62HF6AoVi+q2/K/c7EVs8lhdsYzg jpxdLDkLXuI= =iDKJ -----END PGP SIGNATURE----- --=-5zbMBhTHEEOqToivqcsV--