grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Centralizing understanding of far pointers


From: Javier Martín
Subject: Re: [PATCH] Centralizing understanding of far pointers
Date: Wed, 29 Jul 2009 02:40:33 +0200
User-agent: Thunderbird 2.0.0.22 (Windows/20090605)

-----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-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]