On Thu, Jul 27, 2006 at 02:32:05PM -0700, Zach Brown ([email protected]) wrote:
>
> >> int kevent_getevents(int event_fd, struct ukevent *events,
> >> int min_events, int max_events,
> >> struct timeval *timeout);
> >
> > I used only one syscall for all operations, above syscall is
> > essentially what kevent_user_wait() does.
>
> Essentially, yes, but the differences are important. It's important to
> have a clear syscall interface instead of nesting through multiplexers.
> And we should get the batching/latency inputs right. (I'm for both
> min/max elements and arguably timeouts, but I could understand not
> wanting to go *that* far.)
I completely agree that existing kevent interface is not the best, so
I'm opened for any suggestions.
Should kevent creation/removing/modification be separated too?
> > Hmm, it looks like I'm lost here...
>
> Yeah, it seems my description might not have sunk in :). We're giving
> userspace a way to collect events without performing a system call.
And why do we want this?
How glibc is supposed to determine, that some events already fired and
such requests will return immediately, or for example how timer events
will be managed?
> > I especially like idea about world happinness in a week or so :)
>
> A few weeks! :)
No matter after couple of millions of years of human evolution :)
> - z
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
