| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [Qemu-devel] [PATCH 12/13] set vnc password from xen
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
|
|
|
| |
|
Home