[libvirt] anyone implementing host device enumeration?
Daniel Veillard
veillard at redhat.com
Fri Oct 3 15:57:34 UTC 2008
On Fri, Oct 03, 2008 at 09:57:43AM -0400, David Lively wrote:
> 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.
ahh, cool :-)
> > 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.
okay
> > 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.
yes, for example if you want a blind asynch operation instead
of waiting for the result.
> >
> > > +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).
Create/Destroy has the good point of being similar to other libvirt
functions.
> > 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 ...
okay, thanks.
> > 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.
thanks a lot for pushing this forward :-)
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel at veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
More information about the libvir-list
mailing list