Re: [libvirt] anyone implementing host device enumeration?
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