On Thu, 7 Jan 2010, Michael S. Tsirkin wrote: > 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. You seem to think in one dimension only ;) The interface needs to be stable for everyone. > Maybe yes. I'll think it over and get back to you. Thanks! Let me know. - Davide -- 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
