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.
> * figure out how devkit and HAL correlate, so we report device
info
> consistently
This is looking like it'll be much harder than I had anticipated.
Yeah, I struggled for a while trying to reconcile them. But devkit's
not even close to complete yet, so I gave up. I'm assuming that, since
there are a lot of HAL -> DevKit conversions to be done, some kind of
(probably domain-specific) method(s) of correlating the two will
eventually be described.
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.).
> +struct _stringv {
> + int len;
> + char **const base;
> + const int maxlen;
> +};
> +
> +typedef struct _stringv stringv;
Perhaps I'm mis-undersatnding what this does, but isn't this
similar to the virStringList class in internal.h ?
Well, it's a vector instead of a singly-linked list. I use it when I
know the max length ahead of time (while the list is used in pool source
discovery code that knows of no limit on the number of sources it will
find). I could use a list for the former case, but that would require
an extra copy of each name (plus unnecessary alloc/dealloc code for the
list).
> +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 ???
> + /* TODO: Can we avoid this copy? */
> + xml = strdup((const char *)xmlBufferContent(buf));
Yes, you can with the libvirt buf.h APIs :-)
But if I have to have to call xmlNodeDump, I can't avoid it ...
Thanks for the comments!
Dave