[libvirt] anyone implementing host device enumeration?

[David Lively]

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