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