[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Upstream QEMU based stubdom and rump kernel
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |