On Wed, Jan 06, 2010 at 03:59:11PM -0800, Davide Libenzi wrote: > 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. > I agree it's better to have interface that can't be misused. I was just pointing out that users *can* break recursion by looking at event type. > > 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
