Re: [take12 0/3] kevent: Generic event handling mechanism.

Nicholas Miell
2006-08-22T09:30:18Z

On Tue, 2006-08-22 at 12:37 +0400, Evgeniy Polyakov wrote:
> On Tue, Aug 22, 2006 at 01:17:52AM -0700, Nicholas Miell (nmiell@comcast.net) wrote:
> > On Tue, 2006-08-22 at 11:24 +0400, Evgeniy Polyakov wrote:
> > > On Tue, Aug 22, 2006 at 12:00:51AM -0700, Nicholas Miell (nmiell@comcast.net) wrote:
> > > > On Mon, 2006-08-21 at 14:19 +0400, Evgeniy Polyakov wrote:
> > > > > Generic event handling mechanism.
> > > >
> > > > Since this is the sixth[1] event notification system that's getting
> > > > added to the kernel, could somebody please convince me that the
> > > > userspace API is right this time? (Evidently, the others weren't and are
> > > > now just backward compatibility bloat.)
> > > >
> > > > Just looking at the proposed kevent API, it appears that the timer event
> > > > queuing mechanism can't be used for the queuing of POSIX.1b interval
> > > > timer events (i.e. via a SIGEV_KEVENT notification value in a struct
> > > > sigevent) because (being a very thin veneer over the internal kernel
> > > > timer system) you can't specify a clockid, the time value doesn't have
> > > > the flexibility of a struct itimerspec (no re-arm timeout or absolute
> > > > times), and there's no way to alter, disable or query a pending timer or
> > > > query a timer overrun count.
> > > >
> > > > Overall, kevent timers appear to be inconvenient to use and limited
> > > > compared to POSIX interval timers (excepting the fact you can read their
> > > > expiry events out of a queue, of course).
> > >
> > > Kevent timers are just trivial kevent user.
> > > But even as is it is not that bad solution.
> > > I, as user, do not want to know which timer is used - I only need to
> > > get some signal when interval completed, especially I do not want to
> > > have some troubles when timer with given clockid has disappeared.
> > > Kevent timer can be trivially rearmed (acutally it is always rearmed
> > > until one-shot flag is set).
> > > Of course it can be disabled by removing requested kevent.
> > > I can add possibility to alter timeout without removing kevent if there
> > > is strong requirement for that.
> > >
> >
> > Is any of this documented anywhere? I'd think that any new userspace
> > interfaces should have man pages explaining their use and some example
> > code before getting merged into the kernel to shake out any interface
> > problems.
>
> There are two excellent articles on lwn.net

Google knows of one and it doesn't actually explain how to use kevents.

> >
> > OK, so with literally a dozen different interfaces to queue events to
> > userspace, all of which are apparently inadequate and in need of
> > replacement by kevent, don't you want to slow down a bit and make sure
> > that the kevent API is correct before it becomes permanent and then just
> > has to be replaced *again* ?
>
> I only though that license issues remains unresolved in that
> linux-kernel@ flood, but not, I was wrong :)
>
> I will ask just one question, do _you_ propose anything here?
>

struct sigevent sigev = {
.sigev_notify = SIGEV_KEVENT,
.sigev_kevent_fd = kev_fd,
.sigev_value.sival_ptr = &MyCookie
};

struct itimerspec its = {
.it_value = { ... },
.it_interval = { ... }
};

struct timespec timeout = { .. };

struct ukevent events[max];

timer_t timer;

timer_create(CLOCK_MONOTONIC, &sigev, &timer);
timer_settime(timer, 0, &its, NULL);

/* ... */

kevent_get_events(kev_fd, min, max, &timeout, events, 0);

Which isn't all that different from what Ulrich Drepper suggested and
Solaris does right now. (timer_create would probably end up calling
kevent_ctl itself, but it obviously can't do that unless kevents
actually support real interval timers).

--
Nicholas Miell <nmiell@comcast.net>