On Saturday 29 July 2006 18:18, Ulrich Drepper wrote: > Evgeniy Polyakov wrote: > > Btw, why do we want mapped ring of ready events? > > If user requestd some event, he definitely wants to get them back when > > they are ready, and not to check and then get them? > > Could you please explain more on this issue? > > If of course makes no sense to enter the kernel to actually get the > event. This should be done by storing the event in the ring buffer. > I.e., there are two ways to get an event: > > - with a syscall. This can report as many events at once as the caller > provides space for. And no event which is reported in the run buffer > should be reported this way > > - if there is space, report it in the ring buffer. Yes, the buffer > can be optional, then all events are reported by the system call. > > > So the use case would be like this: > > > wait_and_get_event: > > is buffer empty ? > > yes -> make syscall > > no -> get event from buffer > > > To avoid races, the syscall needs to take a parameter indicating the > last event checked out from the buffer. If in the meantime the kernel > put another event in the buffer the syscall immediately returns. > Similar to what we do in the futex syscall.
Couldn't this be done in a general way: Given a fd that supports streaming input, map some user-mem as a ring buffer for input. Maybe the kernel should control the buffer in order to make resizing possible (i.e., TCP zero-copy and window scaling). Hans Henrik - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
