On 03/27/2012 06:01 PM, Laine Stump wrote:
Sorry for taking so long to actually review this patch. (The fact
that
it didn't apply cleanly (neither the version you sent in email, nor the
version attached to
https://bugzilla.redhat.com/784767) put it just
beyond the threshold of action (the method you used to generate/send the
patch resulted in a corrupt patch that couldn't be applied with "git am"
or "git am -3"). In general, it's best to send patches to the mailing
list with "git send-email", or failing that, by running "git
format-patch", then attaching the result to a mail message (git
send-email is *greatly* preferred).)
(In the end, I pasted the chunks into my work tree by hand.)
Your patch addresses one specific case (interface type is 'bridge', and
doesn't change, but the bridge name does change) of a large class that
could/should be handled (e.g. switch between type='network' and
type='bridge', optionally bounce the link to force a DHCP refresh,
optionally detach/reattach the device if required (e.g. to switch
between macvtap and standard bridge connections)).
And if I'm not mistaken, there's also talk on the qemu list about
implementing a way to make qemu inform at least the virtio net driver in
the guest to do a DHCP refresh, such as after a migration, as another
aspect of things to think about.
My opinion is that the existing patch can go in as a useful starting
point, and we can expand on it (if someone else has a differing opinion,
please say so!)
Other than the minimal functionality, I only saw few nits in the code,
which can be fixed up before pushing, so ACK from me, but we may want to
wait until after the freeze is over and 0.9.11 is released to push.
I'm okay if it goes in now, before any second release candidate is
built, but since you have some cleaned up nits in your tree, I'll let
you be the ultimate judge of when to push.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org