[libvirt] [PATCH 10/10] network: internal API functions to manage assignment of physdev to guest
Laine Stump
laine at laine.org
Sun Jul 10 06:15:19 UTC 2011
On 07/08/2011 04:23 PM, Eric Blake wrote:
> On 07/05/2011 10:18 PM, Laine Stump wrote:
>> I realized that PATCH 10/10 would cause the build to fail if someone
>> did a build --with-qemu but --without-network. I'm squashing the
>> following into the original patch to remedy that.
>>
>> I'm not really a fan of putting #if all over the place, but this is
>> similar to what's done with WITH_MACVTAP, so at least there's
>> precedence. (This is necessary because this new "backend API" to the
>> network driver isn't called via a pointer table filled in at runtime,
>> as is done with the public API).
> Would it be any easier to instead guarantee that even when #if
> WITH_NETWORK is false, those same symbols are available as no-ops to
> allow compilation to proceed?
That would mean either defining the functions inside qemu, or creating a
dummy network module replacement to be built when WITH_NETWORK is false.
I like both of those options even less.
>> +#if WITH_NETWORK
>> /* If appropriate, grab a physical device from the configured
>> * network's pool of devices, or resolve bridge device name
>> * to the one defined in the network definition.
>> */
>> if (networkAllocateActualDevice(net)< 0)
>> goto error;
>> -
>> +#endif
> That is, make networkAllocateActualDevice() be a no-op that returns 0 if
> there is no network support compiled in, and therefore nothing to allocate.
But where would that NOP function live? The natural place for a function
called "networkSomething" is in a network driver, but there isn't one.
>> +++ b/tests/Makefile.am
>> @@ -319,8 +319,11 @@ endif
>>
>> if WITH_QEMU
>>
>> -qemu_LDADDS = ../src/libvirt_driver_qemu.la \
>> - ../src/libvirt_driver_network.la
>> +qemu_LDADDS = ../src/libvirt_driver_qemu.la
>> +
>> +if WITH_NETWORK
>> +qemu_LDADDS += ../src/libvirt_driver_network.la
>> +endif
> Then again, if you are compiling --without-network, you don't want to
> link against a library that won't be built. That would imply that any
> no-op stubs would have to be provided by static inline functions in the
> header in the no-network case.
Ah, you're doing this mail "On the Road" style (stream of consciousness
with no going back to edit), so I'll respond that way too :-)
Actually, I like this idea - in bridge_driver.h, I can put the function
declrations inside #if WITH_NETWORK, and have a #else clause that
contains inlines that return success but do nothing (exactly what is
needed). That way the code in qemu won't need #if.
I'll do it that way in the next version.
More information about the libvir-list
mailing list