On Fri, Jul 28, 2006 at 11:33:16AM -0700, Zach Brown ([email protected]) wrote:
>
> > 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?
>
> Yeah, I think so.
So, I'm going to create kevent_create/destroy/control and kevent_get_events()
Or any better names?
> >>> 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?
>
> So that event collection can be very efficient.
>
> > 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?
>
> ...
>
> That was what my previous mail was all about!
Some events are impossible to create in userspace (like timer
notification, which requires timer start and check when timer
completed).
Actually all events are part of the kernel, since glibc does not have
any knowledge about in-kernel state machines which are bound to
appropriate kevents, so each kevent takes at least two syscall (create
and get ready), and I do not see how, for exmple, glibc can avoid them
when user requested POLLIN or similar event for network dataflow?
According to syscall speed on Linux, last time I checked empty syscall
took about 100ns on AMD Athlon 3500+.
> - 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]
