From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH] libxl: slightly refine pci-assignable-{add, remove} handling Date: Tue, 15 Sep 2015 10:31:36 +0100 Message-ID: <1442309496.3549.351.camel@citrix.com> References: <55F1958602000078000A1AEE@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZbmaT-0005QJ-V6 for xen-devel@lists.xenproject.org; Tue, 15 Sep 2015 09:31:42 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Jan Beulich Cc: xen-devel , Ian Jackson , Wei Liu , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Mon, 2015-09-14 at 10:50 +0100, George Dunlap wrote: > On Thu, Sep 10, 2015 at 1:36 PM, Jan Beulich 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 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 > > 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 > > --- > > 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.