2010/11/29 Paul Brook <paul@xxxxxxxxxxxxxxxx>: >> >> 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. > > Ah, now we're getting somewhere. So you're saying that these devices are > broken anyway, and Kemari happens to trigger that brokenness more frequently? > > If the requirement is that a device must support live migration, then that > should be the criteria for enabling Kemari, not some arbitrary whitelist. Sorry, I though that criteria to be obvious one and didn't think to clarify. The whitelist is a guard not to let users get into trouble with arbitrary devices. > If devices incorrectly claim support for live migration, then that should also > be fixed, either by removing the broken code or by making it work. I totally agree with you. > AFAICT your current proposal is just feeding back the results of some fairly > specific QA testing. I'd rather not get into that game. The correct response > in the context of upstream development is to file a bug and/or fix the code. > We already have config files that allow third party packagers to remove > devices they don't want to support. Sorry, I didn't get what you're trying to tell me. My plan would be to initially start from a subset of devices, and gradually grow the number of devices that Kemari works with. While this process, it'll include what you said above, file a but and/or fix the code. Am I missing what you're saying? 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
