On 07/14/2011 03:42 AM, Daniel P. Berrange wrote: >> >> It turns out that we've used internal-use flags before. See how >> libvirt.c filters out flags in both virDomainGetXMLDesc and >> virSecretGetValue if the flags are larger than 0xffff, so that it can >> start internal flags at 1<<16. Regarding the networking code and our >> discussions on whether we should split out a second internalFlags >> argument rather than cramming internal and external flags into a single >> parameter, I think we should be consistent. > > The difference is that this was an internal impl detail not exposed > in the public headers, so could be removed at any time. > >> Meanwhile, I've got a patch to libvirt.c; I think virDomainGetXMLDesc >> should reject an attempt to pass 1<<16, rather than silently ignore it. > > No, that would not be a good idea, because libvirt.c is in the code > path for the remote client, as well as the server side. But we don't pass internal flags over the wire. That is, the only time we use internal flags is from within the same executable, where we don't go through daemon/remote.c, and therefore don't re-feed the request through src/libvirt.c, therefore are not impacted by libvirt.c rejecting internal flags. > We don't > want todo any flag filtering on the remote client side at all, since > we can't expect the client & server to be on the same versions. Flag > filtering can only be done after dispatch via the internal driver > table, eg in QEMU, LXC, etc directly. That would be a valid concern if we passed internal flags over the wire, but we don't. -- Eric Blake eblake@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list