[Libvir] Fix handling of HVM boot parameters
Daniel Veillard
veillard at redhat.com
Thu Aug 10 14:35:57 UTC 2006
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 at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
More information about the libvir-list
mailing list