Re: [Xen-devel] [PATCH v2 2/4] xenbus: limit when state is forced to closed

From: JÃrgen GroÃ
Date: Wed Dec 11 2019 - 05:21:24 EST


On 11.12.19 11:14, Durrant, Paul wrote:
-----Original Message-----
From: Roger Pau Monnà <roger.pau@xxxxxxxxxx>
Sent: 11 December 2019 10:06
To: Durrant, Paul <pdurrant@xxxxxxxxxx>
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Juergen
Gross <jgross@xxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>;
Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
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.

Juergen