Re: [patch, rfc] lt-epoll ( level triggered epoll ) ...

[bert hubert]

On Tue, Mar 11, 2003 at 10:20:38AM -0800, Davide Libenzi wrote:

> > Most programs will not abandon 'legacy' interfaces like poll and select and
> > will only want to offer epoll in addition. Right now that is hard to do.
> 
> I agree here. It took 15 minutes to port thttpd to LT epoll.

Having level ability will massively speed up epoll adoption. By the way, was
there a reason to go to edge in the first place? 

> I received a bunch of private emails ( ppl that are using ET epoll )
> asking me to have both behaviours. The code require no more than 10 lines
> of code to give both possibilities. We have two options in doing that :

Impressive. 

> We add a parameter to epoll_create() that will set the interface behaviour
> at creation time :
...
> We can go at fd granularity by leaving the API the same, and we define :
> 	#define EPOLLET (1 << 31)

This last option would retain the current ABI *and* semantics for unchanged
programs. I do wonder if there is a case where you'd want to run in mixed
mode, however. But if the code to support mixed operation is truly trivial,
I think we should not set policy from the kernel ('only do epoll in one
mode') and leave it up to userspace to discover if there is a use for this.

Anyhow, as a member of the kCowSay [1] association of userspace people
meddling in the affairs of kernel coders, I vote strongly for having level
triggered epoll on the kernel, with the ability to do mixed mode.

Regards,

bert

[1] Founded by John Levon on the assumption that kernel coders assume all
    userspace code to be trivial, so we should have a massively trivial
    name. kCowSay tries to educate kernel deities about the needs of us
    userspace dwellers.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting