[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