On 08.09.2015 15:14, Jiri Denemark wrote: > On Tue, Sep 08, 2015 at 13:43:09 +0300, Nikolay Shirokovskiy wrote: >> Current implementation of 'toURI' migration interfaces does not support all >> combinations of interface versions and protocol versions. For example 'toURI2' >> with p2p flag will not migrate if driver supports only v3params proto. > > In general, this patch is pretty large and hard to review, I suggest > splitting it into a series of several shorter patches. They all need to > compile and work, but it shouldn't be too hard in this case. > >> This is not convinient as drivers that starts to support migration have to >> manually support older versions of protocol. I guess this should be done in >> one place, namely here. > > Well, the thing is all the code you're changing runs on a *client* and > then the appropriate API calls are sent as RPC to a daemon. So just > checking what APIs are implemented by the *client's* remote driver to > choose what API will be called on the daemon is wrong. The client can be > new enough to support all migration APIs while the daemon may be pretty > old supporting only a few of them. Thus, for backward compatibility, the > client has to either check what API is supported by the daemon (via > VIR_DRV_SUPPORTS_FEATURE(..., VIR_DRV_FEATURE_MIGRATION_...)) or it has > to be conservative and call the oldest API which supports the parameters > passed by the application/user. This approach(namely checking driver capabilities beforehand) is already present in code and i dont change it. > > Overall, if you see a way to refactor and improve the code so that it's > more readable and maintainable, just go ahead, but be careful about this > kind of changes in behavior. > Ok. I'll split into a more managable patches. > Jirka > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list