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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list