Ulrich Drepper writes:
>> epoll does hook f_op->poll() and hence uses the asm/poll.h bits.
> It does today. We are talking about "you promise that this will be
> the case ever after or we'll cut your head off".
> [...]
> it is not you who has to deal with the fallout of a change when it
Maybe Davide wouldn't, but *I* do; my project at work runs over epoll,
and interface changes would require rework by me.
Sensible interface changes in the future won't bother me. I don't
expect anything in the future nearly as earth-shattering as this
current driver/ioctl->syscall transition.
> If epoll is so different from poll (and this is what I've been told
> frmo Davide) then there should be a clear separation of the
> interfaces and all those arguing to unify the data types and
> constants better should rethink there understanding.
The main call returns a subset of the information that poll returns.
What could be more natural than to name that subset the same thing?
Really, sys_epoll does two things:
1 It sets up epoll itself.
This interface is entirely epoll-specific, and has all EP-specific
constants etc, in <sys/epoll.h>, as well it should.
2 It returns the set of poll bits that have changed since the last
epoll.
This interface is defined largely in terms of poll, and that's OK.
How many changes do you expect in the poll interface?
In the end, I don't really feel all that strongly about this bits
issue (since truth be told the performance impact will be very small
at most) so it's up to you and Davide.
OTOH, I really hate the "user pointer in struct epollfd" thing...
-- Grant Taylor - gtaylor<at>picante.com - http://www.picante.com/~gtaylor/ Linux Printing Website and HOWTO: http://www.linuxprinting.org/ - 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:24 EST