If epoll only returns 'bald events' that like electrons are
indistinguishable, userspace will have to do expensive accounting. In fact,
work on MTasker (http://ds9a.nl/mtasker) already necessitated additional
accounting in user space in order to report events back to the right task.
Such double accounting really hurts epoll scalability benefits and means
doing work in the wrong place. It is like we now have kallsyms - the kernel
is well suited to contain that data and do the work. A weaker example is the
in-kernel module loader.
Another solution might be to have the kernel assign an id on epoll_ctl
insert time and store that in the struct. As we are unlikely to have >2^31
events in flight, 32 bits would suffice easily.
But in any case - the cost of preventing 'malicious users' from storing a
single pointer in the kernel is massive amounts of double work. We are in
that case not offering a useful interface.
So from me as an application & library developer, please do the opaque
pointer thing. By the way, Davide, do you think the time is ripe to wrap up
the manpages now? I could finalize them if you want.
-- http://www.PowerDNS.com Versatile DNS Software & Services http://lartc.org Linux Advanced Routing & Traffic Control HOWTO - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/