> -----Original Message----- > From: Roger Pau Monné <roger....@citrix.com> > Sent: 11 December 2019 10:06 > To: Durrant, Paul <pdurr...@amazon.com> > Cc: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org; Juergen > Gross <jgr...@suse.com>; Stefano Stabellini <sstabell...@kernel.org>; > Boris Ostrovsky <boris.ostrov...@oracle.com> > Subject: Re: [Xen-devel] [PATCH v2 2/4] xenbus: limit when state is forced > to closed > > On Tue, Dec 10, 2019 at 11:33:45AM +0000, Paul Durrant wrote: > > If a driver probe() fails then leave the xenstore state alone. There is > no > > reason to modify it as the failure may be due to transient resource > > allocation issues and hence a subsequent probe() may succeed. > > > > If the driver supports re-binding then only force state to closed during > > remove() only in the case when the toolstack may need to clean up. This > can > > be detected by checking whether the state in xenstore has been set to > > closing prior to device removal. > > > > NOTE: Re-bind support is indicated by new boolean in struct > xenbus_driver, > > which defaults to false. Subsequent patches will add support to > > some backend drivers. > > My intention was to specify whether you want to close the > backends on unbind in sysfs, so that an user can decide at runtime, > rather than having a hardcoded value in the driver. > > Anyway, I'm less sure whether such runtime tunable is useful at all, > so let's leave it out and can always be added afterwards. At the end > of day a user wrongly doing a rmmod blkback can always recover > gracefully by loading blkback again with your proposed approach to > leave connections open on module removal. > > Sorry for the extra work. >
Does this mean you don't think the extra driver flag is necessary any more? NB: now that xenbus actually takes module references you can't accidentally rmmod any more :-) Paul _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
