[libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

[Anthony Liguori]

On 03/23/2010 10:57 AM, Paul Brook wrote:
>>> I think there is a serious divergence of approach there, instanciating
>>> API stating 'we are gonna deprecate them sooner or later' tell the
>>> application developper 'my time is more important than yours' and not
>>> really something I like to carry to the API users.
>>> The main goal of libvirt remains to provide APIs needed to unify the
>>> development of the virtualization layers. Having APIs which makes
>>> sense only for one or 2 virtualization engines is not a problem in
>>> itself, it just raises questions about the actual semantic of that API.
>>> If that semantic is sound, then I see no reason to not add it, really
>>> and we actually often do.
>>>        
>> Yeah, but the problem we're facing is, I want there to be an API added
>> to the management layer as part of the feature commit in qemu.  If there
>> has to be a discussion and decisions about how to model the API, it's
>> not going to be successful.
>>      
> I thought the monitor protocol *was* our API. If not, why not?
>    

It is.  But our API is missing key components like guest enumeration.  
So the fundamental topic here is, do we introduce these missing 
components to allow people to build directly to our interface or do we 
make use of the functionality that libvirt already provides if they can 
plumb our API directly to users.

Regards,

Anthony Liguori

> Paul
>