Okay, I see what you mean. I'll create a virNodeDeviceDefPtr and follow
the established pattern.
I'm really trying to avoid creating a struct/union that must be extended
every time we support a new capability. I struggled quite a bit with
the right representation for capabilities and bus details.. At one
point, I had my own (general-purpose; i.e., not specific to any type of
capability) virNodeDeviceCapabilities type, but it looked so much like a
DOM tree that just using a xmlNode seemed like the best choice.
Are you suggesting creating a struct for each kind of
currently-supported capability, or are you suggesting creating a single
struct that's general enough to represent all capabilities?
Dave
On Fri, 2008-10-03 at 16:23 +0100, Daniel P. Berrange wrote:
There should then be a separate file handling configuration parsing
and formatting, node_device_conf.h/.c. There is probably no need
for a state object, so skip virNodeDeviceObjPtr, and just create a
virNodeDeviceDefPtr representing the XML format as a series of
structs/unions, etc. See virDomainDefPtr for a good example. This
should not store any xmlNodePtr instances - it should be all done
as explicit struct/enum fields
The node_device_conf.c file should at mimium have 2 methods, one
for converting an XML document into a virNodeDeviceDefPtr object,
and one for the converting a virNodeDeviceObjPtr back into an XML
document. Follow the existing API naming / method signatures that
are seen in domain_conf.h / network_conf.h for current 'best practice'
Daniel