Re: [libvirt] anyone implementing host device enumeration?

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.

> 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.).

> > +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 ???