Re: [PATCH 09/29] bcache: Convert to bdev_open_by_path()

From: Coly Li <colyli@suse.de>
To: Eric Wheeler <bcache@lists.ewheeler.net>
Cc: Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Bcache Linux <linux-bcache@vger.kernel.org>,
	Kent Overstreet <kent.overstreet@gmail.com>
Subject: Re: [PATCH 09/29] bcache: Convert to bdev_open_by_path()
Date: Wed, 23 Aug 2023 18:10:06 +0800	[thread overview]
Message-ID: <280FD38B-FD92-4995-834F-E3E69CEA49E8@suse.de> (raw)
In-Reply-To: <4c14b62-22a-e9b4-ab2d-3272d0c0495e@ewheeler.net>

> 2023年8月22日 02:54，Eric Wheeler <bcache@lists.ewheeler.net> 写道：
> 
> On Mon, 21 Aug 2023, Jan Kara wrote:
>> On Sun 20-08-23 18:06:01, Eric Wheeler wrote:
>>> On Fri, 11 Aug 2023, Jan Kara wrote:
>>>> Convert bcache to use bdev_open_by_path() and pass the handle around.
>>>> 
>>>> CC: linux-bcache@vger.kernel.org
>>>> CC: Coly Li <colyli@suse.de
>>>> CC: Kent Overstreet <kent.overstreet@gmail.com>
>>>> Acked-by: Coly Li <colyli@suse.de>
>>>> Signed-off-by: Jan Kara <jack@suse.cz>
>>>> ---
>>>> drivers/md/bcache/bcache.h |  2 +
>>>> drivers/md/bcache/super.c  | 78 ++++++++++++++++++++------------------
>>>> 2 files changed, 43 insertions(+), 37 deletions(-)
>>>> 
>>>> diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
>>>> index 5a79bb3c272f..2aa3f2c1f719 100644
>>>> --- a/drivers/md/bcache/bcache.h
>>>> +++ b/drivers/md/bcache/bcache.h
>>>> @@ -299,6 +299,7 @@ struct cached_dev {
>>>> struct list_head list;
>>>> struct bcache_device disk;
>>>> struct block_device *bdev;
>>>> + struct bdev_handle *bdev_handle;
>>> 
>>> It looks like you've handled most if not all of the `block_device *bdev` 
>>> refactor.  Can we drop `block_device *bdev` and fixup any remaining 
>>> references?  More below.
>> 
>> Well, we could but it's a lot of churn - like 53 dereferences in bcache.
>> So if bcache maintainer wants to go this way, sure we can do it. But
>> preferably as a separate cleanup patch on top of this series because the
>> series generates enough conflicts as is and this will make it considerably
>> worse.
> 
> A separate cleanup patch seems reasonable, I'll defer to Coly on this one 
> since he's the maintainer.  I just wanted to point out the possible issue.  
> Thanks for your work on this.

Yes, the challenge of this series is from the block layer core, once the change in core part is accepted, the cleanup can be followed up if necessary.

Thank you all.

Coly Li