Re: [PATCH v2 6/6] Add a general description of the channel mechanism to docs/misc/

[Ian Campbell <Ian.Campbell@citrix.com>]

On Wed, 2014-06-18 at 15:37 +0100, Dave Scott wrote:
> > Is this stuff all forward compatible with the existing xenconsoled etc?
> > What stops it trying to manage these guys?
> 
> To handle this through xenconsoled would involve:

What I meant was why does xenconsoled not try and manage these today and
get in the way? To which the answer is:

> 1. extending xenconsoled to watch for console device backends (like
> any other device backend). Currently xenconsoled is limited to the
> initial console only.

This (which I wasn't aware of, I thought it handled multiple).

ISTR there is a key in their which allows qemu or xenconsoled to provide
this initial console too.

> I took the qemu approach for the initial implementation because this
> is how libxl arranges for  the second/third/fourth/… consoles to be
> served (possibly because xenconsoled has never been extended).
> Personally I’d like to switch over to xenconsoled eventually rather
> than rely on qemu for ever more stuff.

I'll defer to Stefano on this. I thought the normal qemu (upstream)
approach was:

      * emulated stuff via command-line/qmp but never xenstore (in
        contrast with qemu-trad which played all sorts of tricks to
        insert IDE disks from xenstore).
      * PV stuff via watching xenstore backend paths.

Do I understand you correctly that there is a qemu patch involved in all
this, or does it just happen to work if you feed it the correct cmdline
runes?


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