> 2010/11/29 Paul Brook <paul@xxxxxxxxxxxxxxxx>: > >> >> Could you formulate the constraints so developers are aware of them > >> >> in the future and can protect the codebase. How about expanding the > >> >> Kemari wiki pages? > >> > > >> > If you like the idea above, I'm happy to make the list also on > >> > the wiki page. > >> > >> Here's a different question: what requirements must an emulated device > >> meet in order to be added to the Kemari supported whitelist? That's > >> what I want to know so that I don't break existing devices and can add > >> new devices that work with Kemari :). > > > > Why isn't it completely device agnostic? i.e. if a device has to care > > about Kemari at all (of vice-versa) then IMO you're doing it wrong. The > > whole point of the internal block/net APIs is that they isolate the host > > implementation details from the device emulation. > > You're right "theoretically". But what I've learned so far, > there are cases like virtio-net and e1000 woks but virtio-blk > doesn't. "Theoretically", any emulated device should be able to > get into the whitelist if the event-tap is properly implemented > but sometimes it doesn't seem to be that simple. > > To answer Stefan's question, there shouldn't be any requirement > for a device, but must be tested with Kemari. If it doesn't work > correctly, the problems must be fixed before adding to the list. What exactly are the problems? Is this a device bus of a Kemari bug? If it's the former then that implies you're imposing additional requirements that weren't previously part of the API. If the latter, then it's a bug like any other. Paul -- 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
