在 2012-11-16五的 11:21 +0100，Jiri Denemark写道： > On Mon, Nov 12, 2012 at 09:26:30 +0800, li guang wrote: > > 在 2012-11-09五的 13:00 +0100，Jiri Denemark写道： > > > On Fri, Nov 09, 2012 at 10:57:23 +0800, li guang wrote: > > > > > > Well, and that's the thing that actually needs fixing. The migration code in > > > libvirt.c and the code doing peer-to-peer migration in qemu_migration.c are > > > very similar because they are doing almost the same job (only at different > > > levels). It makes sense to change them both at the same time. Why do you want > > > to avoid changing code in libvirt.c? > > > > first, I think it's clean enough for my patch to do offline migration, > > second, someone told me to keep public API stability of libvirt > > before(it's not clear who and when), so I fear to change. > > Well, don't worry I'm aware of API/ABI stability we need to maintain in > libvirt and I wouldn't suggest you to do something that would break anything > in that area. Of course you can't add new parameters to existing public > functions, for example. But changing the code inside to support new flags is > allowed. > Okay. > > you mean I should take care of fixing or re-factoring redundant code > > this time? maybe I can try to do something after this patch. > > No. It's just that the migration code in libvirt.c and the p2p code in > qemu_migration.c are very similar since they are doing the same thing at > different levels. You can't really refactor that and I'm not asking you to do > so. However, since the code logic is similar in both places, it's wise to keep > it that way and just skip Perform phase for offline migrations regardless on > the actual type of migration. I'd much like to see that rather than hacking > somewhere inside the code doing Perform phase to exit if it notices it should > not have been run at all. > > Jirka -- li guang lig.fnst@xxxxxxxxxxxxxx linux kernel team at FNST, china -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list