[libvirt] anyone implementing host device enumeration?

[Daniel P. Berrange]

On Fri, Oct 03, 2008 at 11:02:55AM -0400, David Lively wrote:
> On Tue, 2008-09-30 at 19:02 +0100, Daniel P. Berrange wrote:
> > On Tue, Sep 30, 2008 at 12:17:27AM -0400, David Lively wrote:
> 
> >  - Split stateful drivers out of libvirt.so, so they're only used
> >    by the daemon, and not apps linking to libvirt.so.
> > 
> >    This solves the licensing problem that HAL/DeviceKit introduce
> >    libvirt.so needs to be LGPL to allow closed-source apps to link
> >    to it. HAL/DeviceKit are both GPL or AFL licensed, by virtue
> >    of using DBus. Since LGPL is not AFL compatible, if we link to
> >    HAL/DeviceKit/DBus we do so under the GPL, and thus would
> >    prevent closed source apps using libvirt.so We don't want this,
> >    so we ned to make sure only the libvirtd daemon links to the
> >    GPL bits.
> 
> Ok.  I see.  Will do.

No, no don't do that !  I've already got this work underway, since it
impacts much more than just the host device drivers. Just carry on
with your existing way, and when its ready to merge it'll be easy to
tweak the makefile to have it build in a suitable way.

> > So I'm thinking perhaps we need to simplify our modelling a little
> > so its not so closely replicating HAL, getting rid of the distinct
> > elements for 'class' and 'bus' and having a device simply have a
> > 'subsystem'. And instead of having a complete tree hierarchy, have
> > a specialized hierarchy. eg if we can identify a 'usb' or 'pci'
> > device parent for a device, then include its name, but don't
> > claim to provide a full hierarchy.
> 
> Yes!  I find the distinction between bus and capability to be pretty
> arbitrary anyway (being on a bus is a type of capability, IMO).
> 
> So I'll drop the "bus" stuff, and combine bus capabilities with the
> other capabilities.
> 
> > 
> > The other interesting question, is what policy we should define
> > for compatability. Do we absolutely need to have compatible
> > keys & names for devices, whether using HAL vs DeviceKit, or
> > can be just say that the format of a name is opaque and liable
> > to change ? This has upgrade implications, for example, if we
> > ship libvirt with a HAL backend in Fedora 10, and then switched
> > it to the DeviceKit backend in Fedora 11, do we need to ensure
> > consistent naming across the upgrade path. I don't know...
> 
> Right.  I was hoping to find a consistent set of keys/names to use, but
> gave up.  (sysfs-paths seemed the most common denominator, but not all
> HAL devices have sysfs-paths, and I think the HAL names look more
> appropriate anyway.)  I'm hoping that devkit will eventually add a
> property that either specifies or is convertible to a HAL name.
> 
> Also, if names are really unique (as specified), then why have separate
> keys?  I'd prefer dropping the Key functions and using Name as the key
> (as we do for storage pools, etc.).

The ultimate goal with the storage was that 'key' was unique & consistent
for the same storage on every host the storage was attached to, while
'name' could vary across machines. 

This distinction doesn't entirely apply to host devices, so perhaps
droping key is OK - we could always re-add it later if we found a
compelling need.

> 
> > > +static char *nodeDeviceDumpXML(virNodeDevicePtr dev,
> > > +                               unsigned int flags ATTRIBUTE_UNUSED)
> > > +{
> > > +    xmlBufferPtr buf = xmlBufferCreate();
> ...
> > > +    xmlBufferCCat(buf, "</key>\n");
> > This should use the libvirt buffer routines from buf.h which
> > ensure you don't ignore return values indicating OOM like
> > you have here :-) See buf.h, or HACKING file for some examples.
> 
> Note I call xmlNodeDump(buf, ...).  I suppose the right thing to do is
> to add virBufNodeDump(...) to use libxml to dump into a virBuf  ???

Ok, this actually makes me notice another problem - I'll reply
to the original patch with details. In summary though, the internal
data structure should not be using an xmlNodePtr as its canonical
form, and thus there should not be a need for xmlNodeDump.


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|