[libvirt] anyone implementing host device enumeration?
David Lively
dlively at virtualiron.com
Fri Oct 3 13:57:43 UTC 2008
On Tue, 2008-09-30 at 19:31 +0200, Daniel Veillard wrote:
> Good to see that you seems to have the python bindings ready too !
Many python bindings are not really ready (in this patch). But I should
have them in the next patch (Monday/Tuesday next week).
I have complete java bindings for the current API, and will submit them
once we agree upon it.
> I wonder how many of them should be future-proofed by adding them
> a final flags argument too ... For example it may be useful to only
> lookup devices which are local to the machine, or the opposite only
> remote devices. We don't have to specify now flags values, but having
> the APIs ready is sufficient.
> The virNodeNum/virNodeListDevices devices can probably all share
> the same flags definitions when needed.
I agree. I'll add a flags arg to virNodeNum*/virNodeList*.
> The LookupByName/LookupByKey may be able to use the same set. I wonder
> a bit about the key argument though, I assume it's something actually
> defined by the lower APIs (hal/devkit).
As long as the lookup keys are unique, I don't see why we'd want a flags
arg for these functions.
Currently the key is implementation- (HAL- or Devkit-) dependent, but I
have questions about that (and for that matter, the name arg -- if it's
unique, why have a separate key??). Dan B brings up some similar
points, so I'll address this in my response to his post rather than
here.
> For virNodeDeviceCreate maybe a flags may be needed too, though the
> flexibility of the API is provided by the XML.
I think the XML should provide sufficient flexibility here. But let me
know if you really want me to add a flag arg.
>
> > +int virNodeDeviceDestroy (virNodeDevicePtr dev);
> > +
> > +int virNodeDeviceFree (virNodeDevicePtr dev);
>
> Maybe Destroy need flags too, for example to force (or not)
> destruction of devices which may be in use.
Ok, I'll add a flags arg to Destroy as well. FWIW, I'm not wild about
the names virNodeDeviceCreate/Destroy. Don't "Attach" and "Detach" make
more sense? If there are no objections, I'll change those in my next
iteration (though I'll still leave them unimplemented).
>
> >
> > @@ -332,6 +340,12 @@ skip_function = (
> > 'virCopyLastError', # Python API is called virGetLastError instead
> > 'virConnectOpenAuth', # Python C code is manually written
> > 'virDefaultErrorFunc', # Python virErrorFuncHandler impl calls this from C
> > + 'virNodeDeviceGetKey',
> > + 'virNodeDeviceGetName',
> > + 'virNodeDeviceGetParentKey',
> > + 'virNodeDeviceGetBus',
> > + 'virNodeDeviceNumOfCaps',
> > + 'virNodeDeviceListCaps',
> > )
>
> Strange how are the accessors supposed to work from python then ?
They don't. They're just here so you don't get errors building the
Python bindings. I'll implement real bindings for these soon.
> Hum, the libvirt_lxc really need to link to the device discovery libs ?
I was making host device enumeration work for ALL hypervisors (though of
course the remote driver has a remote impl), so I think this is
necessary. But that said, I'm still digesting Dan B's point about
licensing issues, and I really have no clue about how lxc and openvz
work with libvirt (do they have separate control daemons, like Xen, or
are they more like QEMU, or ???).
> > virLibConnError(virConnectPtr conn, virErrorNumber error, const char *info)
> > virLibConnWarning(virConnectPtr conn, virErrorNumber error, const char *info)
>
> you really need to export them ?
Oh, uhhh, apparently not :-) (I did at one point, but must have removed
that code.) I'll un-export them ...
> Hum ... we need the comment on the accessors, so they get extracted
> as part of the API when doing 'make rebuild' in docs/ added to the
> resulting XML, which then will provide the python accessors
> automatically I think.
Will do.
Thanks for the response. I'll implement the things discussed here (plus
in Dan B's comments - another response coming) and submit a new patch on
Monday or early Tuesday next week.
Dave
More information about the libvir-list
mailing list