Re: [libvirt] anyone implementing host device enumeration?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]