Re: [PATCH] libxl: slightly refine pci-assignable-{add, remove} handling

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

On Mon, 2015-09-14 at 10:50 +0100, George Dunlap wrote:
> On Thu, Sep 10, 2015 at 1:36 PM, Jan Beulich <JBeulich@suse.com> wrote:
> > While it appears to be intentional for "xl pci-assignable-remove" to
> > not re-bind the original driver by default (requires the -r option),
> > permanently losing the information which driver was originally used
> > seems bad. Make "add; remove; add; remove -r" re-bind the original
> > driver by allowing "remove" to delete the information only upon
> > successful re-bind.
> 
> I would be open to the argument that I was being overly paranoid in
> making "xl pci-assignable-remove" not re-bind by default.  But either
> way:
> 
> Reviewed-by: George Dunlap <george.dunlap@citrix.com>

The use of "rc" to hold a non-libxl error code (0 or -1 in this case) in
_add is not allowed by libxl coding style, but is consistent with the same
thing existing in _remove, also this code is mostly in hypervisor coding
style so it seems tolerable for this new code to be so too.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> > In the course of this I also noticed that binding information is lost
> > when upon first "add" pciback isn't loaded yet, due to its presence not
> > being checked for early enough. Adjust pciback_dev_is_assigned()
> > accordingly, and properly distinguish "yes" and "error" returns in the
> > "add" case (removing a redundant error message from the "remove" path
> > for consistency).
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > ---
> > As to 4.6 I'm not overly fussed: It'd be nice, but it could easily be
> > backported later on.
> 
> I wouldn't really consider this a bug fix, but an improvement.  As
> such, I don't think it should be given a freeze exception, and my
> inclination would be to say that it shouldn't be backported.  But the
> strength of my opinion isn't very strong.

I wouldn't argue either way.

Ian.