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