Re: [take5 0/4] kevent: Generic event handling mechanism.

[Zach Brown <zach.brown@oracle.com>]

Evgeniy Polyakov wrote:
> Generic event handling mechanism.
> 
> I send this patchset for comments and review, it still contains AIO and 
> aio_sendfile() implementation on top of get_block() abstraction, which was
> decided to postpone for a while (it is simpler right now to generate patchset as a whole,
> when kevent will be ready for merge, I will generate patchset without AIO stuff).

I think that's the wrong order.  Let's see the clean patch before
deciding to merge it.  Just remove the current aio_sendfile
implementation.  We can build up one that is suitable for merging once
the kevent core is ready for merging.

> Since number of suggested changes goes from 'several' to 'very small', I'm asking for 
> inclusion or declining.

Well, I'm a little confused.  It still seems like we have a long way to
go before having something that we'll want to merge.  There's still
trivial things that need fixing like using LIST_POISON outside list.h
and that nutty 1 second "default" timeout thing, both previously
mentioned.  Then there's much more fundamental stuff like still
returning events from the _wait() syscall.  I thought the notion was
that the wait syscall would only wait and that events were always to be
collected from the ring.

David, what do you think about the networking calls in here?  Are they
suitable for merging?  I've been assuming that you'll want much more
code re-use, but I don't remember seeing you say either way.

There's also something that's been bugging me that I want to ask the
crowd.  The kevent work is doing the same thing fs/aio.c did: for an API
to support async operation we duplicate its existing system call API.
In fs/aio.c it was IO_CMD_* and struct uiocb members, with kevent it's a
system call like sys_aio_sendfile().  This seems like it might get to be
a little much if we bring async support to much of networking, disk io,
and say timers.  That's a lot of interfaces to duplicate.  Is this the
direction we want to take?  One could imagine doing a wrapper syscall
that might allocate a kevent struct and hang it off task_struct for
subsystems to recognize and work with, but that'd bring different
trade-offs.

> Should I prepare final patchset and what should it include?

Can you address the things I mentioned last time I looked through the
code and remove the parts of the patch that we know aren't going to be
merged?

- z