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(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org