Messages in this thread | | | Date | Mon, 18 Nov 2002 10:37:43 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [rfc] epoll interface change and glibc bits ... |
| |
On Mon, 18 Nov 2002, Mark Mielke wrote:
> On Mon, Nov 18, 2002 at 08:05:32AM -0800, Davide Libenzi wrote: > > 1) epoll's event structure extension > > I received quite a few request to extend the event structure to have space > > for an opaque user data object. The eventpoll event structure will turn to > > be : > > struct epollfd { > > int fd; > > unsigned short int events, revents; > > unsigned long obj; > > }; > > As long as people most people make use of 'obj', this > will be a good thing. > > I would be tempted to go the read(), read64() route on this. It makes > everything a mess, but it probably means a more efficient > implementation.
At that point I prefer to have it directly a 64bit int.
> > 2) epoll bits in glibc > > I was talking to Ulrich Drepper about adding epoll bits inside glibc. His > > first objection was to store epoll bits inside poll.h, that IMHO is wrong > > because epoll semantics are completely different from poll(). My idea of > > the <sys/epoll.h> include file would be this : > > ... > > But he does not like epoll to include <bits/poll.h> and he would like > > epoll to redefine POLLIN, POLLOUT, ... to EPOLLIN, EPOLLOUT, ... > > In my opinion it is right for epoll to include <bits/poll.h> because those > > are bits that f_op->poll() returns, and renaming those bits inside another > > include file will require more maintainance. If the kernel will be > > extended to support more POLL* bits, they will have to go only inside > > <bits/poll.h> w/out having another file to be updated IMHO. > > If you can guarantee that epoll will always be compatible with poll() in > terms of objects that can be watched, and events that can be watched, I > would lean towards your preference. If this guarantee cannot be made, I > would lean toward Ulrich's preference.
epoll does hook f_op->poll() and hence uses the asm/poll.h bits.
- 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/
| |