On 09/28/2012 10:14 AM, Laine Stump wrote:
On 09/21/2012 05:16 PM, Kyle Mestery wrote:
> Add the ability for the Qemu V3 migration protocol to
> include transporting network configuration. A generic
> framework is proposed with this patch to allow for the
> transfer of opaque data.
Functionally this all looks good (and sounds like it lives up to that in
practice :-). There are some code style issues, though...
2) Internally, we usually store the enum value rather than the
string,
and translate to/from string form during XML parse/format. (For some
reason, normal usage is to specify it in the struct as an int, with a
comment giving the actual type:
int vporttype; /* enum virNetDevVPortProfile */
I'm not sure why that is, to be truthful - Eric or Dan?)
For public API - ABI stability. The C standard does not give any
guarantees about the sizeof an enum member in a struct, and at least gcc
allows compiler flags that change struct layout based on whether enums
are packed to the smallest integer size that holds all the values of the
enum or is as wide as an int. Since we don't control the compiler flags
used by a client app that includes our public headers, we're better off
avoiding the issue. Using 'int' instead of the enum type frees us from
the ABI questions.
For private API - consistent coding style. Besides, C is not as
typesafe as C++ with regards to enums, so it's not like we're losing
much functionality.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org