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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-10-07 at 17:52 +0100, Dave Scott wrote:
> >>> 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

udev upstream, I think? We also ship some in xen.git but they are more
for backend stuff (which makes sense). For guest side I think udev
upstream is probably the most appropriate place since you want it
everywhere.

> 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 fully agree with your sequencing.

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

I've quickly glanced through the review of this and most of it looked
pretty minor, perhaps it would be worth spinning up the version with
those fixed for consideration?

The most major comment I saw was this one from Ian J which Wei reposted
as:

        Ian Jackson asked one question which remained unanswered in the last
        iteration.
        
        QUOTE
        There are also unfortunate security implications to reading the
        backend directory like that - if we have a driver domain, the qemu
        might get untrustworthy paths.
        ENDQUOTE
        
        Has that question become moot? Did I miss anything?
        
        Wei.


> 
> Cheers,
> Dave
> 



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