> -----Original Message----- > From: Jürgen Groß <[email protected]> > Sent: 11 December 2019 10:21 > To: Durrant, Paul <[email protected]>; Roger Pau Monné > <[email protected]> > Cc: [email protected]; [email protected]; Stefano > Stabellini <[email protected]>; Boris Ostrovsky > <[email protected]> > Subject: Re: [Xen-devel] [PATCH v2 2/4] xenbus: limit when state is forced > to closed > > On 11.12.19 11:14, Durrant, Paul wrote: > >> -----Original Message----- > >> From: Roger Pau Monné <[email protected]> > >> Sent: 11 December 2019 10:06 > >> To: Durrant, Paul <[email protected]> > >> Cc: [email protected]; [email protected]; > Juergen > >> Gross <[email protected]>; Stefano Stabellini <[email protected]>; > >> Boris Ostrovsky <[email protected]> > >> 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 :-) > > I'd like it to be kept, please. >
Ok. I'll leave this patch alone then. Paul > Juergen _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
