Re: [Xen-devel] [PATCH v3 2/3] libxl: add support for channels

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

Hi Ian,

Thanks for the review!

On 23 Jun 2014, at 15:52, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:

> David Scott writes ("[PATCH v3 2/3] libxl: add support for channels"):
>> A 'channel' is a low-bandwidth private communication channel that
>> resembles a physical serial port.
>> 
>> This patch adds a list of channels to the IDL for the domain config.
>> Each channel has a 'kind' which describes what should happen to
>> the data. Currently defined kinds are:
>> 
>>  * PTY: the I/O surfaces as a pty in the backend domain
>>  * SOCKET: a listening Unix domain socket accepts a connection in
>>    the backend domain and proxies
> 
> I don't think the term "kind" here is particularly aposite.  The
> "kind" here doesn't affect the guest protocol - it just controls how
> the device appears in the guest.
> 
> We currently use a variety of device-specific terms for the
> information which specifies the host resources to be exposed for any
> particular virtual device.  Eg, "pdev" for disks; "bridge" for vifs.
> 
> The word "backend" is attractive but is used for disks to refer to the
> specific provisioning strategy (choice of implementation).
> 
> Perhaps "method" or "connection".  Consulting a thesaurus yielded
> "style", "disposal", "usage", "disposition", "associate" ("assoc"?),
> "termination" ("term"?).

OK, I’ll mull over some of the options.

> 
>> Channels are implemented using PV consoles backed by qemu (not
>> xenconsoled).
> 
> Why should an additional channel not be handled by xenconsoled and
> logged ?

I believe the current situation (unchanged by these patches) is that 
xenconsoled is only capable of handling console 0, but that qemu is capable of 
handling all consoles. Console 0 has always been a bit special: pre-configured 
by the domain builder and ending up in a special place in xenstore. Consoles 1+ 
are treated more like regular devices (with state = … keys etc), and end up in 
/local/domain/%d/device/console/%d.

My plan was to build these ‘channel’ things on top of the existing additional 
console support, which happens to rely on qemu. It would be nice to teach 
xenconsoled about these new channels/consoles but I thought I’d try a simple 
implementation first. This should all be hidden behind the interface so we can 
change the implementation later.

> 
>> Channels may be listed but don't currently support hotplug/unplug.
> 
> It might be easier to wait with the listing until after Wei's
> save/restore changes.

Thanks for the heads-up — I’ll check out Wei’s changes.

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