Re: [Xen-devel] xl, libxl: add support for 'channels'

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 7 Oct 2014, Dave Scott wrote:
> On 26 Sep 2014, at 20:20, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 
> 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@xxxxxxxxxx> 
> >>> 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?

Sorry for not reading the thread earlier: too many people CC me
nowadays, I didn't notice you ask me something :-/


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

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