> The real question here is which interface we want people to use for > these "combined" applications. Evgeny is heavily pushing kevent for > this while other seem to prefer integration epoll into the aio > interface. (1)> > I must admit that kevent seems to be the cleaner way to support this, > although I see some advantages for the aio variant. I do think > however that we should not actively promote two differnt interfaces > long term.

i see no fundamental disadvantage from doing both. That way the 'market' of applications will vote. (we have 2 other fundamental types available as well: sync IO and poll() based IO - so it's not like we have the choice between 2 or 1 variant, we have the choice between 4 or 3 variants)

> (1) note that there is another problem with the current kevent> interface, and that is that it duplicates the event infrastructure > for it's underlying subsystems instead of reusing existing code > (e.g. inotify, epoll, dio-aio). If we want kevent to be _the_ > unified event system for Linux we need people to help out with > straightening out these even provides as Evgeny seems to be > unwilling/unable to do the work himself and the duplication is > simply not acceptable.

yeah. The internal machinery should be as unified as possible - but different sets of APIs can be offered, to make it easy for people to extend their existing apps in the most straightforward way.(In fact i'd like to see all the 'poll table' code to be unified into this as well, if possible - it does not really "poll" anything, it's an event infrastructure as well, used via the naive select() and poll() syscalls. We should fix that naming mistake.)