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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/