[libvirt] PATCH: 7/12: Public API for node devices

[Mark McLoughlin]

On Fri, 2008-11-14 at 13:28 +0000, Daniel P. Berrange wrote:
> On Fri, Nov 14, 2008 at 12:46:09PM +0000, Mark McLoughlin wrote:
> > 
> > On Thu, 2008-11-13 at 17:30 +0000, Daniel P. Berrange wrote:

> > > +
> > > +virNodeDevicePtr        virNodeDeviceLookupByName (virConnectPtr conn,
> > > +                                                   const char *name);
> > > +
> > > +const char *            virNodeDeviceGetName     (virNodeDevicePtr dev);
> > > +
> > 
> > How stable are these names? e.g. should we say that no-one should rely
> > on the format of the name and that the name of a given device could
> > change across node reboots? Even if HAL guarantees the name to be stable
> > (does it?), if you switch between HAL and DevKit it could change, right?
> 
> I don't think HAL explicitly guarentees it, it merely happens to have
> been stable AFAICT. The naming is definitely completely different
> between HAL and DevKit.
> 
> This is probably my biggest worry with the impl so far - some app
> using it will need to have a stable identifier for a device and we
> won't be providing it. 

I don't have a good understanding of what this API will be used for,
aside from device passthrough.

I wouldn't be surprised if we decide that it makes sense to allow using
higher level names for passthrough, rather than e.g. PCI IDs - i.e.
passthrough "device with mac address X" rather than vendor:device or
bus:dev.func.

In that case, you need the names to be stable, but you don't necessarily
need them to have a predictable enough structure that people can
construct a name themselves.

> We could invent our own stable naming scheme for devices - the scheme
> would vary per capability - eg for PCI devices we can use the bus,
> function, slot identifiers. USB is hard to guarentee though - if a
> device is plugged in & unpluged & plugged in again it won't get the
> same address, and there's no real other identifier we can rely on
> for this.

I think the key thing in the short term is that we make it clear that
device names are completely unstable identifiers with no structure or
meaning that can be relied upon.

I'd almost be tempted to append a few bytes of randomness to the names
for now ...
 
> Separating the physical from logical devices gives us the opportunity
> to define more stable names for devices with certain capabilities.
> eg, for a USB network card, its hard to invent a stable name at the
> level of the USB device, but for the logical NIC you can easily invent
> a name based off the MAC address.

Another way would be to have multiple names for each device, by
aggregating the "PCI device" and "network device" capabilities into a
single object.

The only really advantage to that would be that given a less specialized
name for a device, you could easily iterate over the more specialized
names. But if we need that we could add virNodeDeviceListChildren() I
guess.

IOW, the current scheme will probably work out just fine ...

Cheers,
Mark.