Re: [Xen-devel] [PATCH v3 1/3] docs: add a document describing the 'channels' mechanism

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-06-24 at 12:15 +0100, Dave Scott wrote:
> On 24 Jun 2014, at 11:43, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> 
> > Dave Scott writes ("Re: [PATCH v3 1/3] docs: add a document describing the 
> > 'channels' mechanism"):
> >> On 23 Jun 2014, at 15:53, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> >>> I forgot to ask: what will a guest do that doesn't understand these
> >>> special-purpose "console"s ?
> >> 
> >> In a Linux VM theyâll just appear as /dev/hvcX devices. I assume something 
> >> similar in a *BSD.
> > 
> > ... and then what would happen with them ?  Nothing ?  If so, fine.
> > 
> > I'm just worried that something might automatically mess with them.
> > E.g. I have found a horrid thing called "modem-manager" on some
> > desktop Linuces which opens (all?) serial devices and tries blathering
> > AT commands at themâ
> 
> The uses for these channels all involve talking to some specific
> software inside the guest, for example an âearly configurationâ
> service or a guest agent. It only makes sense to connect a channel to
> a guest if your guest has been configured to expect it. You would
> install your VM as normal, install your special software, shutdown,
> add the channels, possibly clone/publish your guest as a template and
> then restart.
> 
> Youâre right that an unconfigured or misconfigured guest could do
> anything in theory. Your AT command scenario sounds quite realistic
> and would make a good example in the docs of why in-guest
> configuration is necessary.
> 
> I think I should elaborate more on the use-cases in the docs to make all this 
> clearer.

it also implies that the backend should be tolerant of frontends talking
nonsense at them, but of course that's also true for security reasons...

Ian.


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