WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [Qemu-devel] [PATCH 12/13] set vnc password from xen

To: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 12/13] set vnc password from xenstore.
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Tue, 26 Aug 2008 11:13:40 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, qemu-devel@xxxxxxxxxx, Gerd Hoffmann <kraxel@xxxxxxxxxx>
Delivery-date: Tue, 26 Aug 2008 03:14:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48ADCCA2.8050201@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Newsgroups: chiark.mail.xen.devel
References: <1219336054-15919-1-git-send-email-kraxel@xxxxxxxxxx> <1219336054-15919-13-git-send-email-kraxel@xxxxxxxxxx> <48ADCCA2.8050201@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Anthony Liguori writes ("[Xen-devel] Re: [Qemu-devel] [PATCH 12/13] set vnc 
password from xenstore."):
> I don't really like this approach.  I don't want to have a totally 
> separate management interface just for Xend to use (via xenstore).

I agree that the xenstore management approach is not right for qemu.
It would be better to go through a more stable interface.

> Can't Xend use the monitor like every other management tool?

I think it probably could.  When I was doing my initial work to start
merging our tree with the qemu one, I didn't do this because I wanted
a drop-in replacement for the older code, and because I ran out of
time.

But as others have noted there are also two things which the monitor
doesn't do which we would need: multiple monitors, and the ability for
a monitor client to wait for events.  We need multiple monitors so
that a monitor remains available to those people whose Xen
installations are already making use of it.

In the new scheme of things I envisage a xenstore <-> qemu-monitor
conversion layer.  This would work much like the way xenstore.c works
in our Xen qemu tree does.  It probably ought not to be part of xend,
and I think I would still like it to be compiled as part of our qemu
build.

If upstream qemu don't want a bevy of alternative management veneers
around the main qemu binary in their tree then I don't think there
would be a problem with us maintaining that indefinitely in our
version.  The important thing is not which tree the code is in, but
that we should go through a stable interface intended by qemu upstream
to be used for this kind of thing.

So I would suggest that the starting point would be to provide for
multiple monitors.  Then, we can gradually change the code in our
tree's xenstore.c to go via the monitor (adding functionality to the
monitor as necessary).  Eventually we'll have a xenstore.c which
doesn't do anything other than go via the monitor at which point
we can either leave things, or include that upstream if desired.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>