Re: [Xen-devel] [PATCH v2 1/6] libxl: add a list of abstract 'channels' to the domain config

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-06-18 at 15:05 +0100, Dave Scott wrote:
> Hi,
> 
> On 18 Jun 2014, at 14:27, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> > On Mon, 2014-06-16 at 10:49 +0100, David Scott wrote:
> >> A 'channel' is a low-bandwidth private communication channel that
> >> resembles a physical serial port. Example uses include:
> >> 
> >>  * providing initial VM configuration without having to use the
> >>    network
> >>  * signalling a guest agent
> >> 
> >> Every channel has a string 'name' which the VM can use to find
> >> the appropriate handler. Each channel has an implementation 'type'
> >> which currently includes:
> >> 
> >>  * NONE: reads will block, writes will be thrown away
> > 
> > What's this useful for?
> 
> I was thinking of this particular one as a â/dev/nullâ equivalent â
> the virtual device is present in the guest (which might be needed to
> trigger some side-effect) but the output isnât important.
> 
> It appealed to me as a kind of a base case, but I grant you that itâs
> not the most useful feature in the world :-)

:-)

It seems to me that triggering a side-effect in the guest without
needing the actual channel is the sort of thing which would be prone to
abuse.

I'd be inclined to leave it out unless/until there is a concrete user
which we can decide is reasonable (or not).

> >>  * PTY: the I/O surfaces as a pty in the backend domain
> >>  * PATH: writes are appended to a log file in the backend domain
> > 
> > PATH is quite a generic name for that.
> 
> Hm, perhaps calling it FILE would be better â this is what libvirt and qemu 
> both use.

That misses the append+write-only aspects of it. I'd naÃvely expect to
be able to point it at a file to be slurped in (like we do for the
qemu-stubdm restore file).

> >>  * SOCKET: a listening Unix domain socket accepts a connection in
> >>    the backend domain and proxies
> 
> The SOCKET type is the most useful kind IMHO.
> 
> So libvirt and qemu support a bunch of other types: TCP connect to â;
> receive connection and proxy â (and probably more in future). Instead
> of trying to mirror the libvirt/qemu APIs we could fall back and only
> support the âSOCKETâ type, and require users to move the data wherever
> they want via a proxy like âsocatâ. These channels are low-bandwidth
> so efficiency is not really a concern.

I don't think we'd have a problem adding more transports as demand
arises, but lets concentrate on the simple ones which meet your usecases
for now instead of imaging all the mad things one might do with this
functionality.

(unless you were suggesting that you wanted the TCP thing, in which case
sorry for calling your use case mad ;-))

> > Is path valid for all types?
> > 
> > If not then a KeyedUnion would be the way to go.
> 
> OK.
> 
> So I think the question Iâm most unsure about is: should we keep the
> notion of âtypeâ here (and switch to a KeyedUnion) or treat everything
> in a uniform way (e.g. socket) and let someone else to the plumbing?

PTY and SOCKET certainly seem distinctly useful to me. FILE as an append
only logging thing seems sort of OK but I've concerns about filling
disks with it.

Ian.


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