[Libvir] [PATCH] hypervisor version
Daniel Veillard
veillard at redhat.com
Mon Jun 18 08:40:47 UTC 2007
On Fri, Jun 15, 2007 at 06:26:53PM -0400, Mark Johnson wrote:
> Saving the dom0 patch for last :-)
>
>
> On 6/15/07, Daniel Veillard <veillard at redhat.com> wrote:
> >On Thu, Jun 14, 2007 at 11:27:21PM +0100, Daniel P. Berrange wrote:
> >> On Thu, Jun 14, 2007 at 05:06:16PM -0400, Mark Johnson wrote:
> >> > This is another patch which may not be popular? Xen's
> >> > extra version does not fit in libvirt's release field (since it's
> >> > part of an int).
> >> >
> >> > Instead of printing out the wrong value, just display
> >> > major.minor in virsh.
> >>
> >> Hmm, so with Xen we have two backend impls of the Version API, one
> >talking
> >> to the hypervisor which only ever returns the first 2 components, and the
> >> other talking to XenD which processes all 3.
> >>
> >> As you say, in practice the extra version from Xen is effectively garbage
> >>
> >> So while as root I see
> >>
> >> # virsh version
> >> Compiled against library: libvir 0.2.2
> >> Using library: libvir 0.2.2
> >> Using API: Xen 3.0.1
> >> Running hypervisor: Xen 3.1.0
> >>
> >> If run as non-root I instead seee
> >>
> >> $ virsh version
> >> Compiled against library: libvir 0.2.2
> >> Using library: libvir 0.2.2
> >> Using API: Xen 3.0.1
> >> Running hypervisor: Xen 3.730.259
> >>
> >>
> >> I think instead of this patch to change the virsh driver though, we
> >should
> >> change teh xend_internal.c file to ignore the extra_version data from
> >XenD
> >> as there's no way to meaningfully interpret it as an int.
> >
> > Agreed, let's fix at the source instead of just dropping the data in
> >the user land tool. I'm more concerned by getting the API right.
>
> I'm not sure where to go from here..
>
> Is the suggestion to change xend_internal/xen_internal to not set rev
> and remove the display of the hypervisor rev in virsh? Or is it something
> else?
Well ideally I would prefer xend to not send something crazy for 'release'
but since that's unlikely, and since the hypervisor only provide major/minor
anyway, let's just drop the release in src/xend_internal.c , I'm suggesting
the enclosed patch,
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/
-------------- next part --------------
Index: src/xend_internal.c
===================================================================
RCS file: /data/cvs/libxen/src/xend_internal.c,v
retrieving revision 1.119
diff -u -r1.119 xend_internal.c
--- src/xend_internal.c 15 Jun 2007 15:24:20 -0000 1.119
+++ src/xend_internal.c 18 Jun 2007 08:39:38 -0000
@@ -2601,8 +2601,7 @@
xenDaemonGetVersion(virConnectPtr conn, unsigned long *hvVer)
{
struct sexpr *root;
- const char *extra;
- int major, minor, release = 0;
+ int major, minor;
unsigned long version;
if (!VIR_IS_CONNECT(conn)) {
@@ -2619,16 +2618,8 @@
major = sexpr_int(root, "node/xen_major");
minor = sexpr_int(root, "node/xen_minor");
- extra = sexpr_node(root, "node/xen_extra");
- if (extra != NULL) {
- while (*extra != 0) {
- if ((*extra >= '0') && (*extra <= '9'))
- release = release * 10 + (*extra - '0');
- extra++;
- }
- }
sexpr_free(root);
- version = major * 1000000 + minor * 1000 + release;
+ version = major * 1000000 + minor * 1000;
*hvVer = version;
return(0);
}
More information about the libvir-list
mailing list