On Thu, Jan 11, 2007 at 12:21:45PM +0100, Philippe Berthault wrote: > Daniel Veillard a écrit : > >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 :-( It can tell you the minimum level of functionality it will contain - ie you have APIs from /at least/ version 0.1.8. There's obviously no way you can encode data about exactly what features are present based on a simple version number. Wrt to whether the Attach/Detach functions are present - the use of the virGetVersion() function is pretty irrelevant because if your app uses them, you'll get an error at build time when trying to link against the library with undefined symbol. Basically treat virGetVersion() as a guide to the minimum available functionality, not as an absolute rule. For things which vary at runtime, the best approach is to simply look for them / try calling them and be prepared to handle errors appropriately if they're not present. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|