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

[Evgeniy Polyakov]

On Tue, Oct 03, 2006 at 11:09:15PM -0700, Ulrich Drepper (drepper@xxxxxxxxx) wrote:
> On 9/22/06, Evgeniy Polyakov <johnpol@xxxxxxxxxxx> wrote:
> >The only two things missed in patchset after his suggestions are
> >new POSIX-like interface, which I personally consider as very unconvenient,
> 
> This means you really do not know at all what this is about.  We
> already have these interfaces.  Several of them and there will likely
> be more.  These are interfaces for functionality which needs the new
> event notification.  There is *NO* reason whatsoever to not make this

It looks I'm a bit puzzled...

Let me clarify my position about it.
Kevent as a generic event handling mechanism should not knwo about how
events were added. It was designed to be quite flexible, so one could
add events from essentially any possible situation.
One of the most common situations is userspace requests - they are added
through set of created syscalls. There can exists tons of quadrillions of
any other interfaces, I even specially created helper function for kernel 
subsystems (existing and new ones) which might want to create events
using own syscalls and parameters. For example network AIO work that way
- it has own syscalls, which parses parameters, creates ukevent
structure and pass them into kevent core, which in turn calls appropriate 
callbacks back to network AIO.

Everyone can add new interfaces in any way he likes, it would quite
silly to created new subsystem which would required strick API and
failed to work with different set of interfaces.

So from my point of view, problem is not in case that 'we need only this
API', but 'why new API is better that old one'.
It is possible to create new API, which will add events from _existing_
syscalls, it is just one function call from given syscall, I completely 
agree with it.
I'm just objecting against removing existing interface in favour of new
one.

People who need POSIX timer API - feel free to call
kevent_user_add_ukevent() from your favorite posix_timer_create().
Who needs signal queueing can do it even in signal() syscall - kevent
callback for that subsystem for example can update process' signal mask
and add kevents.

-- 
	Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/