On Thu, Aug 10, 2006 at 03:15:41PM +0100, Daniel P. Berrange wrote:
On Thu, Aug 10, 2006 at 05:08:58AM -0400, Daniel Veillard wrote:
> Sound sensible, the problem is detecting the version of xend,
> of course you can ask xend, you will get the exact version of the
> compiler used to compile it, but when it comes to xen version itself
> (xen_major 3) (xen_minor 0) (xen_extra -unstable)
> which makes things a bit hard to distinguish 3.0.2 from 3.0.3 :-\
Basically trying to hook off version number is not ever really going
to be reliable because we need libvirt to be able to work against
development snapshots - features may be introduced during dev that need
detecting before the version number is incremented.
sigh, yes
> We could try to use the changest but it's not available in
our build
> either.
Hooking off changeset looks & smells like a nasty hack.
Well that's something we know will increase, and trying to get
versionning from something not versionned will be hackish
What is really needed is a version number for the SEXPR format
returned
by XenD. A simple incrementing integer digit would suffice really.
(xen_sexpr_format 4)
Which could be incremented each time a new capability is introduced,or
an existing one changed. Something to propose upstream asap ?
I'm not sure this will be agreed upon, if you present it that way
since sexpr will be deprecated "soon", but asking for a a rev number in
xend API changes would be logical. But that will be too late for
"ioemu:" anyway ...
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/