[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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"?).

> Channels are implemented using PV consoles backed by qemu (not
> xenconsoled).

Why should an additional channel not be handled by xenconsoled and
logged ?

> 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,
Ian.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.