On 2011-10-21 09:54, Michael S. Tsirkin wrote: > On Fri, Oct 21, 2011 at 09:09:10AM +0200, Jan Kiszka wrote: >> On 2011-10-21 00:02, Michael S. Tsirkin wrote: >>>>> Yes. But this still makes an API for acquiring per-vector resources a requirement. >>>> >>>> Yes, but a different one than current use/unuse. >>> >>> What's wrong with use/unuse as an API? It's already in place >>> and virtio calls it. >> >> Not for that purpose. >> It remains a useless API in the absence of KVM's >> requirements. >> > > Sorry, I don't understand. This can acquire whatever resources > necessary. It does not seem to make sense to rip it out > only to add a different one back in. > >>> >>>> And it will be an >>>> optional one, only for those devices that need to establish irq/eventfd >>>> channels. >>>> >>>> Jan >>> >>> Not sure this should be up to the device. >> >> The device provides the fd. At least it acquires and associates it. >> >> Jan > > It would surely be beneficial to be able to have a uniform > API so that devices don't need to be recoded to be moved > in this way. The point is that the current API is useless for devices that do not have to declare any vector to the core. By forcing them to call into that API, we solve no current problem automatically. We rather need associate_vector_with_x (and the reverse). And that only for device that have different backends than user space models. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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
