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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
