From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Upstream QEMU based stubdom and rump kernel Date: Wed, 18 Mar 2015 16:46:24 +0000 Message-ID: <1426697184.14291.89.camel@citrix.com> References: <20150317142907.GD27314@zion.uk.xensource.com> <20150317151517.GI1345@perard.uk.xensource.com> <20150317152733.GA20522@zion.uk.xensource.com> <1426606710.18247.267.camel@citrix.com> <20150318112407.GE17247@nodbug.moloch.sk> <1426678209.18247.332.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Wei Liu , Ian Jackson , xen-devel@lists.xen.org, rumpkernel-users@freelists.org, Anthony PERARD , Martin Lucina List-Id: xen-devel@lists.xenproject.org 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@citrix.com 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,