On Wed, 6 Jan 2010, Michael S. Tsirkin wrote: > I tried to explain, no? That patch was taking wait queue spinlock and > was assuming that eventfd_read_ctx is called from a task that can block. > KVM attaches its own poller so this is not a good fit for us. Hope this > clarifies. > > > and yet again you managed to add an underscore at the beginning of the > > API name, in an API set where there are no leading underscores. Even > > if KVM does that for its own reasons, you should be able to fit your > > naming "style" to the interface you're adding your droplets into. I > > will post an eventfd_read_ctx() to Andrew ASAP. > > > > > > > > - Davide > > Sorry about the underscore - it's easy to fix but I won't bore you with > more patch revisions before I understand what makes you unhappy. > > Before KVM starts creating workqueues and doing schedule_work calls just > to work around the API, can we discuss this please? I am not hung on my > patch, but could we have it work so that we can call eventfd_read_ctx > from wait queue callback directly? The "read" needs to wake possible OUT waiters, *cannot* be done your way. On top of creating an interface which requires a lock, which noone can get from the interface itself, since it's not exposed. I could split the two and have a locked one, and an unlocked one, but that looks shitty too (for the above reason). I thought you *already* do your own stuff from a work queue, why would you need to read from IRQ context? - 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
