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