Messages in this thread | | | Date | Thu, 21 Nov 2002 00:55:02 +0000 | From | Jamie Lokier <> | Subject | Re: [rfc] epoll interface change and glibc bits ... |
| |
Mark Mielke wrote: > It looks fine to me for as long as we can guarantee that sizeof(void *) > will be less than or equal to sizeof(__uint64_t) (relatively safe).
It is fine, for epoll itself, even if sizeof(void *) > sizeof(__uint64_t).
Conversion functions for legacy 32-bit code running on a 128-bit chip will be more complex, but epoll is the _least_ of problems in that case...
> I still prefer 'userdata' over 'obj', but the name of thing is not very > important to me.
The AIO subsystem has a very similar cookie, which is simply declared as `__u64 aio_data' in user-supplied requests, and returned in the responses. It's converted to a field called `ki_user_data' in the kernel.
Just a few reference points... I like `user_data' myself.
> I'm not sure if this is wise or not, but an 'fd' member might be > useful as well: > [...] > For applications that wish to store fd's (probably common due to > poll() roots), this would help them avoid casting magic as well. Also, > it allows for 64 bit file descriptors if that ever became necessary.
That is a good idea, if we go for the union.
-- Jamie - 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/
| |