|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |