[Libvir] Question about libvirt integration into RHEL-5

[Philippe Berthault]

Daniel Veillard a écrit :
> On Thu, Jan 11, 2007 at 11:42:31AM +0100, Philippe Berthault wrote:
>   
>> Daniel Veillard a écrit :
>>     
>>> On Thu, Jan 11, 2007 at 11:27:52AM +0100, Philippe Berthault wrote:
>>>  
>>>       
>>>> Daniel Veillard a écrit :
>>>>    
>>>>         
>>>>> it is 0.1.8 but with 12 patches which are backport of later bug fixes 
>>>>> or important features like localization, shareable disk support, core 
>>>>> dump support,
>>>>> etc ...
>>>>> I guess it's closer to 0.1.9 as a result than 0.1.8,
>>>>>
>>>>>      
>>>>>           
>>>> Hum ! :-(
>>>> Currently, the version of libvirt determines its unequivocal contents. 
>>>> With a patched version of libvirt, it becomes impossible in an 
>>>> application to known the functionalities level of libvirt if the version 
>>>> number is identical to a non-patched libvirt.
>>>>
>>>> Could you explain how it's possible from an application to distinguish 
>>>> between a patched libvirt and a non-patched libvirt or another patched 
>>>> version of libvirt by using the virGetVersion() function ?
>>>>    
>>>>         
>>>  Can explain your problem instead ?
>>> What is the feature or behaviour you need to detect ?
>>>  
>>>       
>> We have to know if the Attach/Detach devices functions will be in the 
>> libvirt library of RHEL-5 RC1
>>     
>
>   No this was done after the code freeze, and not request by a partner
> as a feature for RHEL-5, so this is not present.
>
>   
>> and also if some enhancements of the XML 
>> format will be present such as currentMemory, ...
>>     
>
> Yes currentMemory will be in. This should not be a big problem, you can generate
> the XML with it, and if the library don't understand it, it should just ignore
> it.
> The set of patches are the following:
>
> Patch0: create_message.patch   -> bug fix
> Patch1: libvirt-0.1.8-shreable-disk.patch -> shareable disk
> Patch2: localization.patch -> localization
> Patch3: core_dump.patch    -> support for domain core dump
> Patch4: current_memory.patch -> current memory amount support
> Patch5: bootloader.patch   -> bug fix for pygrub bootloader
> Patch6: python-lock.patch  -> release python lock when calling libvirt
> Patch7: ostype.patch       -> os type bug fix
> Patch8: vcpu_info.patch    -> bug fix
> Patch9: pvfb.patch         -> Paravirt frame buffer support
> Patch10: pvfb2.patch
> Patch11: maxid_check.patch -> bug fix
>   
Your reply doesn't explain how it will be possible in an application to 
known the functionalities level of libvirt by using the virGetVersion() 
function. For RHEL-5 RC1, we have now the response but this problem will 
occur again in the future with RHEL-5 update-1, update-2, ... and so on.

My understanding is that the virGetVersion() function is useless :-(