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? 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
