[libvirt] anyone implementing host device enumeration?

[David Lively]

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