HI Roman, On Fri, May 31, 2019 at 11:34:08AM +0200, Roman Penyaev wrote: > On 2019-05-27 15:36, Renzo Davoli wrote: > > Unfortunately this approach cannot be applied to > > poll/select/ppoll/pselect/epoll. > > If you have to override other systemcalls, what is the problem to override > poll family? It will add, let's say, 50 extra code lines complexity to your > userspace code. All you need is to be woken up by *any* event and check > one mask variable, in order to understand what you need to do: read or > write, > basically exactly what you do in your eventfd modification, but only in > userspace. This approach would not scale. If I want to use both a (user-space) network stack and a (emulated) device (or more stacks and devices) which (overridden) poll would I use? The poll of the first stack is not able to to deal with the third device. > > > > > Why can it not be less than 64? > > This is the imeplementation of 'write'. The 64 bits include the > > 'command' > > EFD_VPOLL_ADDEVENTS, EFD_VPOLL_DELEVENTS or EFD_VPOLL_MODEVENTS (in the > > most > > significant 32 bits) and the set of events (in the lowest 32 bits). > > Do you really need add/del/mod semantics? Userspace still has to keep mask > somewhere, so you can have one simple command, which does: > ctx->count = events; > in kernel, so no masks and this games with bits are needed. That will > simplify API. It is true, at the price to have more complex code in user space. Other system calls could have beeen implemented as "set the value", instead there are ADD/DEL modification flags. I mean for example sigprocmask (SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK), or even epoll_ctl. While poll requires the program to keep the struct pollfd array stored somewhere, epoll is more powerful and flexible as different file descriptors can be added and deleted by different modules/components. If I have two threads implementing the send and receive path of a socket in a user-space network stack implementation the epoll pending bitmap is shared so I have to create critical sections like the following one any time I need to set or reset a bit. pthread_mutex_lock(mylock) events |= EPOLLIN write(efd, &events, sizeof(events)); pthread_mutex_unlock(mylock) Using add/del semantics locking is not required as the send path thread deals with EPOLLOUT while its siblings receive thread uses EPOLLIN or EPOLLPRI I would prefer the add/del/mod semantics, but if this is generally perceived as a unnecessary complexity in the kernel code I can update my patch. Thank you Roman, renzo
