Re: [PATCH 0/2] eventfd: new EFD_STATE flag

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jan 06, 2010 at 02:46:06PM -0800, Davide Libenzi wrote:
> On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
> 
> > > On top of creating an interface which requires a lock, which noone can get 
> > > from the interface itself, since it's not exposed.
> > 
> > I think here's how KVM gets it: the way it does is by calling poll with
> > our own poll table, then in poll_queue_proc we get wait queue pointer,
> > and we use the wait queue. Lock is in there :)
> 
> Yes, I know you are called locked, but it does not lead to a clean 
> interface.

True.

> > > I could split the two and have a locked one, and an unlocked one, but that 
> > > looks shitty too (for the above reason).
> > 
> > Yes, this will work. Thanks!
> 
> This is a lot more complex than I thought. The wakeup code is already 
> enumerating the list, and doing a wakeup might trigger a secondary 
> enumeration/recursion.

For KVM what you describe is I think is not a problem: we check wake type
and ignore POLLOUT events.

> Do you really need to "consume" the value from IRQ context, or you can 
> simply "peek" the value, and flush it later?
> 
> 
> 
> - Davide

Maybe yes. I'll think it over and get back to you. Thanks!

-- 
MST