On Wed, 20 Nov 2002, Mark Mielke wrote:
> On Thu, Nov 21, 2002 at 12:28:16AM +0000, Jamie Lokier wrote:
> > Davide Libenzi wrote:
> > > typedef union epoll_obj {
> > > void *ptr;
> > > __uint32_t u32[2];
> > > __uint64_t u64;
> > > } epoll_obj_t;
> > > I'm open to suggestions though. The "ptr" enable me to avoid wierd casts
> > > to avoid gcc screaming.
> > That makes more sense to me, because it will be fine to use `ptr' even
> > on 128-bit pointer machines when they arrive, yet preserves the
> > property that 64<->32 bit conversion functions don't need to reformat
> > the buffer when running 32-bit applications on a 64-bit CPU... even if
> > the 32-bit application uses the `ptr' field.
> > Did I just write that? :)
>
> The problem with sizeof(void *) being >= sizeof(__uint64_t) is that the
> data structure is the wrong length. Binary compatibility would not be
> maintained.
>
> Still... I believe that the days of 128-bit pointers are comfortably
> far enough away that it does not cause any concerns at all for me. (I
> suspect the kernel will need quite a few more changes than just this
> to support 128-bit poitners...)
In theory it is possible to pass epoll_create() an extra parameter that
will set the size of the extra data, from 0 up to N. And the kernel will
return this data "as is". It'll become nasty in user space to access data
though.
- 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/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:35 EST