David, I'm sorry but I only briefly looked at the work Evgeniy did on
kevent. So excuse me if I say something broken in the next few sentences.
Zab's async syscall interface is a pretty simple one. It accepts the
syscall number, the parameters for the syscall, and a cookie. It returns a
syscall result code, and your cookie (that's the meat of it, at least).
IMO its interface should be optimized for what it does.
Could this submission/retrieval be inglobated inside a "generic"
submission/retrieval API? Sure you can. But then you end up having
submission/event structures with 17 members, 3 of which are valid at each
time. The API becomes more difficult to use IMO, because suddendly you
have to know which field are good for each event you're submitting/fetching.
IMHO, genericity can be built in userspace, *if* one really wants it and,
of course, provided that the OS gives you the tools to build it.
The problem before, was that it was hard to bridge something like poll/epoll
with other "by nature" sync operations. Evgeniy kevent is one attempt,
Zab's async is another one. IMO the async syscall is a *very poweful* one,
since it allows for *total coverage* async support w/out "plugs" all over
the kernel paths.
But as Zab said, the kernel implementation is more important ATM.
- Davide
-
