Re: [Xen-devel] Upstream QEMU based stubdom and rump kernel

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-03-18 at 12:45 +0000, Stefano Stabellini wrote:
> On Wed, 18 Mar 2015, Ian Campbell wrote:
> > On Wed, 2015-03-18 at 12:24 +0100, Martin Lucina wrote:
> > > ian.campbell@xxxxxxxxxx said:
> > > > On Tue, 2015-03-17 at 15:27 +0000, Wei Liu wrote:
> > > > > This looks most interesting as it implies we can easily pipe a console
> > > > > to it.
> > > > 
> > > > BTW, rather than rawe consoles we should probably consider using the
> > > > channel extension: http://xenbits.xen.org/docs/unstable/misc/channel.txt
> > > 
> > > What would be the advantage/rationale for using channels rather than 
> > > vchan?
> > > (See my other reply to this thread)
> > 
> > Not much really.
> > 
> > About the only relevant difference between vchan and channels(/consoles)
> > is that there is an existing backend running on most xen systems
> > (xenconsoled) which can be leveraged in some cases for channels, whereas
> > vchan would need a specific backend writing for each case.
> > 
> > Apart from that implementation convenience vchan is probably going to be
> > better in terms of proper integration for the other end.
> > 
> > But iff the decision goes the way of consoles then using channels in
> > preference to raw consoles makes sense.
> 
> I think that for simplicity's sake and to limit dependencies on the
> system, using consoles for low bandwidth channels, such as QMP, is
> preferable.

s/consoles/channels/, please ;-)

That said, a having libxl be a user of libvchan to slurp the data in/out
of qemu directly (perhaps using the datacopier infrastructure) might be
nicer from a design point of view, since it would mean libxl could
read/write things directly instead of via a temp file and it takes
xenconsoled out of that path, which might be nice.

Ian,



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel