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 -=|