I definitely wasn't planning on covering all of HAL :-) I assume you weren't planning on exposing these capability-specific representations in the public API. Right? (If not, ignore the rest of this ...) So I guess I don't see the value of having these cap-specific internal representations. I keep a string array of the cap names for ListDevicesByCap, but other than that, the capability data is used only by virNodeDeviceGetXMLDesc(). So it seems natural to represent it in a form that can easily be converted to XML, and that can represent all the XML we'll need to output (like xmlNode). Otherwise, we are forced to write more capability-specific code, with no particular advantage (no stronger typing guarantees if we don't expose specific cap types). Dave P.S. I do think it would be useful to have access to capability details other than GetXMLDesc. Perhaps: const char *virNodeDeviceCapabilityProperty(virNodeDevicePtr dev, const char *cap, const char *prop) but note this exposes them only in a general (property / value) way, and is quite easily implemented with a xmlNode representation. On Fri, 2008-10-03 at 18:41 +0100, Daniel P. Berrange wrote: > On Fri, Oct 03, 2008 at 01:20:35PM -0400, David Lively wrote: > > 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? > > I'm suggesting a something that is specific for each capability. Now > if we were to support all metadata that HAL exposes this would be a > huge job. But I don't believe we should be exposing all the metadata > that HAL has, because in the future this XML format has to work with > DeviceKit which is basically exposing UDev metadata, and VMWare's > APIs which expose hardware info in their own way. > > Thus, IMHO, we should expose specific capabilities we know we care > about, for specific sub-substems, and not try to handle the entire > of HAL. > > A good starting point would be > > - PCI, domain, bus, slot, function, and vendor/product > - USB, bus, device and vendor/product > > Basically same info required for attaching the device to a domain, > thus matching the struct virDomainHostdevDefPtr in domain_conf.h > > - NIC, name & mac address > - Block, name and host adapter > - Host adapter, name > > For these also have a way to link to the parent device associated > with them (ie the PCI/USB device providing them). > > That would basically be enough for use of the existing domain/storage > and network APIs which is what we need this data for, and this minimal > info should be satisifiable with VMWare's APIs, and DeviceKit. > > Regards, > Daniel -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list