On 07/02/2010 06:54 AM, Chris Lalancette wrote: >> Should virDomainDefNamespaceHref take a void* argument... >> >>> + if (def->namespaceData && def->ns.href) >>> + virBufferVSprintf(&buf, " %s", (def->ns.href)()); >> >> and pass def->namespaceData through to that function? I'm a little bit >> nervous about callback functions that cannot be extended, and passing a >> (unused, for now) void* pointer gives us some room for growth without >> changing the API, if need be. > > We could. It's an internal API, though, so we are free to change it at > will later. Fair enough, since it is not exported. >>> static virDomainDefPtr virDomainDefParseXML(virCapsPtr caps, >>> - xmlXPathContextPtr ctxt, int flags) >>> + xmlDocPtr xml, >>> + xmlNodePtr root, >>> + xmlXPathContextPtr ctxt, >>> + int flags) >> >> As long as we are changing this API, should we change flags to unsigned >> int? And should we add a virCheckFlags(VIR_DOMAIN_XML_INACTIVE..., NULL)? > > Again, an internal API, so I guess I could change the flags. Minor change, > though. As far as virCheckFlags() is concerned, my take on it (and it's usage > in the tree up to this point) is always at driver entry points, not > internal API's. While we could add it here, passing bogus flags here is a > programming error, not a user error. Good point - there's a difference between a static function used only internally (we can check all callers in the same file) and a driver callback (where the interface is public, and we can't control the behavior of external programs that link to our library and pass arbitrary flags). So, with my questions addressed, ACK. -- 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