lkml.org 
[lkml]   [2006]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [take12 0/3] kevent: Generic event handling mechanism.
    From
    Date
    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>

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

    \
     
     \ /
      Last update: 2006-08-22 11:33    [W:0.025 / U:2.832 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site