2010/11/29 Paul Brook <paul@xxxxxxxxxxxxxxxx>: >> 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. It's a problem if devices don't continue correctly upon failover. I would say it's a bug of live migration (not all of course) because Kemari is just live migrating at specific points. Yoshi > > 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 > -- 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
