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.