From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dave Scott <Dave.Scott@citrix.com>
Subject: Re: [PATCH v2 6/6] Add a general description of the
 channel mechanism to docs/misc/
Date: Wed, 18 Jun 2014 14:37:56 +0000
Message-ID: <BC30FF6D-7425-451D-BB6C-5611587E9920@citrix.com>
References: <1402912195-24732-1-git-send-email-dave.scott@citrix.com>
	<1402912195-24732-7-git-send-email-dave.scott@citrix.com>
	<1403098902.6568.17.camel@kazak.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Dave.Scott@citrix.com>) id 1WxGzv-0002pU-Tp
	for xen-devel@lists.xenproject.org; Wed, 18 Jun 2014 14:38:00 +0000
In-Reply-To: <1403098902.6568.17.camel@kazak.uk.xensource.com>
Content-Language: en-US
Content-ID: <2F006C3D2E31A44B943832E1C98A4420@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>, Wei Liu <wei.liu2@citrix.com>, Stefano Stabellini <Stefano.Stabellini@citrix.com>, Ian Jackson <Ian.Jackson@citrix.com>
List-Id: xen-devel@lists.xenproject.org

Hi Ian,

On 18 Jun 2014, at 14:41, Ian Campbell <Ian.Campbell@citrix.com> wrote:

> On Mon, 2014-06-16 at 10:49 +0100, David Scott wrote:
>> +  type =3D (NONE | FILE | PTY | SOCKET | ... )
> =

> Are these the literal xenstore key values, shouty caps and all?

In the current qemu-based implementation they don=92t appear in xenstore. I=
nstead xenstore has a reference to a =93-chardev=94 on the qemu command lin=
e.

  /local/domain/$DOMID/device/console/$DEVID/output =3D chardev:libxl-chann=
el0

(for some reason the =91output=92 key is in the frontend. At least it=92s r=
eadonly)

  qemu-system-i386 -M xenpv -chardev socket,id=3Dlibxl-channel0,path=3D%s,s=
erver,nowait

Actually I think it would probably be good to include these keys in xenstor=
e as well even if they aren=92t currently used (minus the shouty caps) sinc=
e then they could be read by console backends in other domains.

> Is this stuff all forward compatible with the existing xenconsoled etc?
> What stops it trying to manage these guys?

To handle this through xenconsoled would involve:

1. extending xenconsoled to watch for console device backends (like any oth=
er device backend). Currently xenconsoled is limited to the initial console=
 only.

2. changing the libxl implementation to remove the -chardevs from the qemu =
command-line and add the keys (type/path) to the backend directory

It ought to be possible to get xenconsoled running in multiple domains and =
choose between them by setting the =91backend=92 in the libxl device.

Importantly no libxl client would need to change.

I took the qemu approach for the initial implementation because this is how=
 libxl arranges for  the second/third/fourth/=85 consoles to be served (pos=
sibly because xenconsoled has never been extended). Personally I=92d like t=
o switch over to xenconsoled eventually rather than rely on qemu for ever m=
ore stuff.

Cheers,
Dave

> =

>> +  path =3D <some path>
>> +
>> +In the default implementation where the backend is run in the toolstack
>> +domain, the qemu "chardev" mechanism is used. This implementation
>> +interprets the configuration as follows:
>> +
>> +  type =3D NONE: the backend will be connected to /dev/null
>> +  type =3D FILE: the channel will be read the the output appended
> =

> "the the".
> =

>> +    to the file given by 'path'
>> +  type =3D PTY: the backend will connect to a PTY like a regular console
>> +  type =3D SOCKET: the backend will accept a connection on the Unix
>> +    domain socket given by 'path' and proxy data to and from the device.
>> +
>> +If the implementation is in another domain (for example via a Mirage
>> +console backend) then the behaviour will be defined by this other domai=
n.
> =

> =