[libvirt] [PATCH 07/10] network: new XML to support virtual switch functionality

Laine Stump laine at laine.org
Sun Jul 17 23:52:49 UTC 2011

On 07/14/2011 10:26 AM, Eric Blake wrote:
> On 07/14/2011 08:14 AM, Daniel P. Berrange wrote:
>> On Thu, Jul 14, 2011 at 08:11:20AM -0600, Eric Blake wrote:
>>> On 07/14/2011 08:08 AM, Daniel P. Berrange wrote:
>>>>> That would be a valid concern if we passed internal flags over the wire,
>>>>> but we don't.
>>>> I'm thinking about the case where a value we currently use for an
>>>> internal flag, gets used for a public flag in the future. In that
>>>> case, any client side checks for curent internal flags would be
>>>> bogus.

Right. That concern is what triggered my code; I fixed that, just didn't 
fix it in the best way.

>>> Then we already have the bogus situation, where libvirt.c is silently
>>> filtering out internal flags.
>> I wasn't aware of any existing filtering - we must remove any such
>> cases.

Yeah, neither was I. I was only aware that we had an internal flags enum 
and a public flags enum, that they shared the same arg, and that there 
was nothing in the code to protect against conflicting bits in the two 
(runtime protection doesn't count :-P)

> Will do - I already had a local patch started for that effort, but I can
> improve it along these lines.

Note that the new version of my patches adds an internalFlags argument 
only to the necessary functions within domain_conf.c, and puts my flag 
there. I purposefully am not doing anything about the existing flag, 
VIR_DOMAIN_XML_INTERNAL_STATUS. I spent several hours attempting a 
"pre-patch patch" to fix INTERNAL_STATUS and add an internalFlags 
argument to *every* function in domain_conf.c, but it became very huge 
very quickly, and was destined to lead to a regression somewhere due to 
my limited time.

BTW, I've noticed that although VIR_DOMAIN_XML_INTERNAL_STATUS is 
defined in domain_conf.h, it isn't actually used outside of 
domain_conf.c, so it doesn't need to be exposed in the .h file.

More information about the libvir-list mailing list