public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Paul Durrant <pdurrant@amazon.com>
Cc: <xen-devel@lists.xenproject.org>, <linux-kernel@vger.kernel.org>,
	"Juergen Gross" <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>
Subject: Re: [Xen-devel] [PATCH v2 2/4] xenbus: limit when state is forced to closed
Date: Wed, 11 Dec 2019 11:06:27 +0100	[thread overview]
Message-ID: <20191211100627.GI980@Air-de-Roger> (raw)
In-Reply-To: <20191210113347.3404-3-pdurrant@amazon.com>

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.

Thanks, Roger.

  reply	other threads:[~2019-12-11 10:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10 11:33 [PATCH v2 0/4] xen-blkback: support live update Paul Durrant
2019-12-10 11:33 ` [PATCH v2 1/4] xenbus: move xenbus_dev_shutdown() into frontend code Paul Durrant
2019-12-10 11:33 ` [PATCH v2 2/4] xenbus: limit when state is forced to closed Paul Durrant
2019-12-11 10:06   ` Roger Pau Monné [this message]
2019-12-11 10:14     ` [Xen-devel] " Durrant, Paul
2019-12-11 10:21       ` Jürgen Groß
2019-12-11 13:29         ` Durrant, Paul
2019-12-10 11:33 ` [PATCH v2 3/4] xen/interface: re-define FRONT/BACK_RING_ATTACH() Paul Durrant
2019-12-10 11:33 ` [PATCH v2 4/4] xen-blkback: support dynamic unbind/bind Paul Durrant
2019-12-11 10:45   ` Roger Pau Monné
2019-12-11 10:52     ` Durrant, Paul
2019-12-11 14:46       ` Durrant, Paul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191211100627.GI980@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pdurrant@amazon.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox