Davide Libenzi wrote:
>On Mon, 18 Nov 2002, Jakub Jelinek wrote:
>
>
>
>>That is as bad as unsigned long - it is different between 32-bit and 64-bit
>>ABIs.
>>
>>
>
>Yeah, you right. I did thin about 32bit and 64bit as two diffferent
>kernel-glibc environment, I did not think about 32-64 ABI compatibility.
>Ouch, adding a 64bit object will double the size of the event structure :(
>
>
>
>- Davide
>
>
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>Yeah, you right. I did thin about 32bit and 64bit as two diffferent
>kernel-glibc environment, I did not think about 32-64 ABI compatibility.
>Ouch, adding a 64bit object will double the size of the event structure :(
>
>
Pros of a 64-bit opaque user pointer:
- Simpler programming for userland.
- Fewer cache misses, because there is no need for accessing part of a
separate and large fd->pointer table in userland before being able to
act upon event notification (some implementations can get around this,
but it's very common practice).
Cons:
- 4 bytes memory wastage on 32-bit platforms per struct. Note that it
is not the full 8, because userland needs to have that table of pointers
anyway.
Notes:
- No memory wastage for nontrivial applications on 64-bit platforms.
Matthew D. Hall
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:25 EST