[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 |