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;
};
and the epoll_ctl() function will turn to :
int epoll_ctl(int epfd, int op, struct epollfd *pfd);
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 :
#ifndef _SYS_EPOLL_H
#define _SYS_EPOLL_H 1
#include <bits/poll.h>
/* Valid opcodes to issue to sys_epoll_ctl() */
#define EP_CTL_ADD 1
#define EP_CTL_DEL 2
#define EP_CTL_MOD 3
struct epollfd {
int fd;
unsigned short int events, revents;
unsigned long obj;
};
__BEGIN_DECLS
extern int epoll_create(int size);
extern int epoll_ctl(int epfd, int op, struct epollfd *pfd) THROW;
extern int epoll_wait(int epfd, struct epollfd *events, int maxevents,
int timeout) THROW;
__END_DECLS
#endif /* sys/epoll.h */
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.
I would like to receive feedback on those issues ...
- 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:22 EST