From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MVz6P-0003zi-E1 for mharc-grub-devel@gnu.org; Tue, 28 Jul 2009 22:41:13 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVz6O-0003zd-Q5 for grub-devel@gnu.org; Tue, 28 Jul 2009 22:41:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVz6K-0003zR-9k for grub-devel@gnu.org; Tue, 28 Jul 2009 22:41:12 -0400 Received: from [199.232.76.173] (port=57512 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVz6K-0003zO-4I for grub-devel@gnu.org; Tue, 28 Jul 2009 22:41:08 -0400 Received: from mail-ew0-f228.google.com ([209.85.219.228]:50921) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MVz6J-0005zB-3w for grub-devel@gnu.org; Tue, 28 Jul 2009 22:41:07 -0400 Received: by ewy28 with SMTP id 28so1075510ewy.42 for ; Tue, 28 Jul 2009 19:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=L6C+PjhsCUeAzwdoSZ17PpdSPIAvFVa0FTaOk6FI774=; b=mHp9yEdxD1uCgGqJjw1FPRo8ZPlvnDB1LzObLht465pdLkf/56gJ7JVpukfZhFZL4+ qsF+aipK38IEXjloWSnzffV7ZpIEZh+bmsnTF3CWR7KBLcZGYQgTsuolA/Lp3CIe5FUx tO0KcDRB2jVS0BVdJTcrc6kQwvkgaiJF6noFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=M2PdGz2tvAL2PjYN2ec9khoT1eXEZar5f7AGwe4R+qXrw2hjtTxHYnHZRlk7BMayOy KuRvBsi6+52V64w7xn+PrmKiYpBdZ2jbmaDFeeJMwfEDXTgwx4KUJHsK6dYJLZt49/NZ qpfZVgT24Xx2lNM4XgutxYsdUNbPapq9+dJh4= Received: by 10.210.125.13 with SMTP id x13mr3388521ebc.38.1248835264447; Tue, 28 Jul 2009 19:41:04 -0700 (PDT) Received: from ?192.168.1.100? (89.141.11.145.dyn.user.ono.com [89.141.11.145]) by mx.google.com with ESMTPS id 28sm1227823eyg.56.2009.07.28.19.41.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Jul 2009 19:41:03 -0700 (PDT) Message-ID: <4A6F9A81.6080209@gmail.com> Date: Wed, 29 Jul 2009 02:40:33 +0200 From: =?UTF-8?B?SmF2aWVyIE1hcnTDrW4=?= User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: The development of GRUB 2 References: <1248561149.4660.245.camel@accesodirecto.casa> <20090728181103.GH32726@thorin> In-Reply-To: <20090728181103.GH32726@thorin> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [PATCH] Centralizing understanding of far pointers 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: Wed, 29 Jul 2009 02:41:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Millan escribió: > First of all, please don't call them far pointers. They're an i8086 legacy > cruft, which have nothing to do with far or close really (although we seem to > have some code that makes this reference already). So... how do we call them? I am an utter failure at making up sensible names. > > What you're doing is basically the same as real2pm() function we already had. > It seems this function should move elsewhere so it can have the generic use > you intended (it can be reimplemented as well, if that makes it cleaner). Indeed, that's what I thought when I saw that function in some vbe-related file. I remembered that I wrote similar code for drivemap, and then reasoned that mmap would used too, as it modified the IVT. Thus, we are uselessly duplicating code that is simple but at the same time error-prone. The idea of this patch is to provide a way to handle the abstraction of a pointer that is somehow mangled by the architecture, but the "user" code doesn't need to actually know how. For example, the patched drivemap would just take whatever linear2real(ptr) gives and stores it into the IVT slot. Of course, this is not as "magical" as an ideal world would have it, because the code still has to know the IVT to place it there, but I think it's still a plus. >> +typedef union >> +{ >> + struct >> + { >> + /* Given that i386 is little-endian, this order matches the in-memory >> + format of CPU realmode far pointers. */ >> + grub_uint16_t offset; >> + grub_uint16_t segment; >> + } __attribute__ ((packed)); >> + grub_uint32_t raw_bits; > > Is there a usefulness in this `raw_bits' member? It doesn't have any > real meaning, as it doesn't correspond to an actual address. Mainly, the possibility of checking equality against a particular bit pattern without using another instance of the structure/union. Also, some code might want to still use the raw bits for some reason, instead of either the nearly-opaque handling described above or the more detailed view provided by the inner structure. > >> +} grub_machine_farptr; > > I admit this is a bit confusing, but the `machine' namespace is for > things specific to a given firmware. i8086 mode is part of the i386 > architecture, so we'd put this in the `cpu' namespace instead. OK then... That means the code will have to move from i386/pc/memory.h to i386/memory.h. And what about x86_64? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJKb5qBAAoJEKSl+Fbdeo72EfMP/0JVO7mO92Pyk9l5tiGP5IQ+ PbrLJBX1HtAemwMufW5wR+OoQjyb9LGf1JR0ff7o7Xkbtnc3iN7EI8RV4WAzuLp3 9tYpYZkIwLWa86GM8Oy8QWer58vNlHYNtH+Zmrv+341umtFZERRjWk6NwpNNgFtm uX8FoYGqHLIhkzLWvd5vM7V+8S9LJPjq2ws/F1NbS5Sd33wTz81eFz6TNmoALNuD KeIR9Vo6f1zN3lp0M9+CL1fzX7uP3e3dWJ+KmOlkJcEJgpsRJhz76Ux9Byq0Tby9 SLXQmEfBmSNk95HpXnn2AFuiH/o8SYyWExPAEbz//Ttym4ElGGfS+tE3d8b7auga Y2ReU8I9XlbMczIjvnh6MaLOwzGuu6mtPFvec5PHSK9sekJ2TWYCosXpUkMo58TS vXPou5VDAkRb6sbuMx8g7fGws5vgYuEYcIZAkW3ejcJhIkMSGODEYRsT2A8ZREzx Qs/B48Z9Tk4nVxdPrIfDg7eB4TtEpJak84uw/fV6/WclY5ipk/SGf0iyhDfuU7vp 6w+6Kbvny0dOyssMz8cN2MlL7DinAtx2Zzi0jVHBNl253Af/idPJAPw69LDFWroN EHjLHxxnnkF4MOiR7WzH49QRzLCuGmMfgnqKEdEW1JxNFqG5+zE0L3p1Sp/pITs7 q+2CU6+NR3veOdzg3yRh =dKOS -----END PGP SIGNATURE-----