On Mon, Nov 29, 2010 at 3:00 PM, Yoshiaki Tamura <tamura.yoshiaki@xxxxxxxxxxxxx> wrote: > 2010/11/29 Paul Brook <paul@xxxxxxxxxxxxxxxx>: >>> > 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? >> >> My point is that the whitelist shouldn't exist at all. Devices either support >> migration or they don't. Having some sort of separate whitelist is the wrong >> way to determine which devices support migration. > > Alright! > > Then if a user encounters a problem with Kemari, we'll fix Kemari > or the devices or both. Correct? Is this a fair summary: any device that supports live migration workw under Kemari? (If such a device does not work under Kemari then this is a bug that needs to be fixed in live migration, Kemari, or the device.) Stefan -- 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
