Re: [Xen-devel] [PATCH v2 6/6] Add a general description of the channel mechanism to docs/misc/

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

Hi Ian,

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

> On Mon, 2014-06-16 at 10:49 +0100, David Scott wrote:
>> +  type = (NONE | FILE | PTY | SOCKET | ... )
> 
> Are these the literal xenstore key values, shouty caps and all?

In the current qemu-based implementation they don’t appear in xenstore. Instead 
xenstore has a reference to a “-chardev” on the qemu command line.

  /local/domain/$DOMID/device/console/$DEVID/output = chardev:libxl-channel0

(for some reason the ‘output’ key is in the frontend. At least it’s readonly)

  qemu-system-i386 -M xenpv -chardev 
socket,id=libxl-channel0,path=%s,server,nowait

Actually I think it would probably be good to include these keys in xenstore as 
well even if they aren’t currently used (minus the shouty caps) since 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 other 
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 ‘backend’ 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/… consoles to be served (possibly 
because xenconsoled has never been extended). Personally I’d like to switch 
over to xenconsoled eventually rather than rely on qemu for ever more stuff.

Cheers,
Dave

> 
>> +  path = <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 = NONE: the backend will be connected to /dev/null
>> +  type = FILE: the channel will be read the the output appended
> 
> "the the".
> 
>> +    to the file given by 'path'
>> +  type = PTY: the backend will connect to a PTY like a regular console
>> +  type = 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 domain.
> 
> 


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