Re: xl, libxl: add support for 'channels'

[Dave Scott <Dave.Scott@citrix.com>]

On 26 Sep 2014, at 20:20, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Fri, Sep 26, 2014 at 04:14:16PM +0100, Ian Jackson wrote:
>> Dave Scott writes ("Re: [Xen-devel] xl, libxl: add support for 'channels'"):
>>> On 25 Sep 2014, at 20:13, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>>> The major piece of information that is missing is - who/what generates
>>>> the udev information in the guest? I could not find it in the Linux
>>>> hvc_console.c driver so I am unclear of how it is suppose to
>>>> work there?
>>> 
>>> I believe all secondary consoles (in device/console/ in xenstore)
>>> generate the event. I’m not familiar with the kernel side of things;
>>> Stefano: can you point us in the right direction?
> 
> 
> Stefano?
> 
> Either way, I think this patch just need to mention what kernel driver
> so that folks who are developing this can check that the required
> kernel driver is loaded (or built).

I checked by deliberately mangling a xenstore key to see where the Linux errors
came from. The logged messages were from “xenconsole” and I got a stack
trace with

  xencons_disconnect_backend
  xencons_probe
  xenbus_dev_probe
  xenbus_frontend_dev_probe
  ..
  xenbus_register_driver_common
  xenbus_register_frontend
  ..
  xen_hvc_init

So it looks like the driver is hvc_xen.c, so people would need
CONFIG_HVC_XEN_FRONTEND. I’ll add that to the patch.


>>> 
>>> For reference I used a udev rule to catch all secondary consoles:
>>> 
>>> # Set up secondary Xen consoles
>>> SUBSYSTEM=="xen", DEVPATH=="/devices/console-[0-9]", RUN+="xenconsole-setup-tty”
>> 
>> I think this should be documented somewhere in the patch, at the very
>> least.  Better would be to submit it upstream.
> 
> +1 in the patch. 
> 
> Upstream being in the libvirt side of the world? Sure - the more the merrier.

:-) My plan is to upstream everything to the most appropriate places so

1. the protocol + API: this patch to libxl,xl,docs/misc (including details of the udev rule)
2. the udev rule itself: to wherever the distros get their udev rules from
3. the libvirt glue: to libvir-devel
4. application-level code to make use of it: to various places

I think the best ordering is to get the foundation ready first (i.e. this patch)
and then promote the rest. It would be risky to push dependent patches anywhere else
until the API has actually been fully released.

I’m a bit torn on the timing: on the one hand I’d really like to get a released API that
I can build on. On the other hand this is definitely a new feature and perhaps
at this stage it’s better to focus on fixing bugs rather than introducing them!

Once I’ve finished a bit of xenstore patch re-reviewing, I can send another spin of
this. However I’m still missing Acks on key patches from the maintainers. So if
you or they would rather focus bandwidth elsewhere, let me know and I’ll hibernate the
patches for 4.6.

Cheers,
Dave