[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <db803720-66a6-4e0e-88ce-6b8a05845146@gmx.com>
Date: Tue, 1 Jul 2025 18:16:33 +0930
From: Qu Wenruo <quwenruo.btrfs@....com>
To: Christian Brauner <brauner@...nel.org>
Cc: Christoph Hellwig <hch@...radead.org>, Qu Wenruo <wqu@...e.com>,
linux-btrfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
viro@...iv.linux.org.uk, jack@...e.cz, linux-ext4@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net, ntfs3@...ts.linux.dev,
linux-xfs@...r.kernel.org
Subject: Re: [PATCH v2 1/6] fs: enhance and rename shutdown() callback to
remove_bdev()
在 2025/7/1 18:11, Christian Brauner 写道:
> On Tue, Jul 01, 2025 at 04:05:03PM +0930, Qu Wenruo wrote:
>>
>>
>> 在 2025/7/1 15:44, Christoph Hellwig 写道:
>>> On Tue, Jul 01, 2025 at 03:02:34PM +0930, Qu Wenruo wrote:
>>>> To allow those multi-device filesystems to be integrated to use
>>>> fs_holder_ops:
>>>>
>>>> - Rename shutdown() call back to remove_bdev()
>>>> To better describe when the call back is called.
>>>
>>> What is renamed back here?
>>
>> Rename the old shutdown to remove_bdev().
>>
>>>
>>>> -static void exfat_shutdown(struct super_block *sb)
>>>> +static void exfat_shutdown(struct super_block *sb, struct block_device *bdev)
>>>> {
>>>> exfat_force_shutdown(sb, EXFAT_GOING_DOWN_NOSYNC);
>>>> }
>>>> @@ -202,7 +202,7 @@ static const struct super_operations exfat_sops = {
>>>> .put_super = exfat_put_super,
>>>> .statfs = exfat_statfs,
>>>> .show_options = exfat_show_options,
>>>> - .shutdown = exfat_shutdown,
>>>> + .remove_bdev = exfat_shutdown,
>>>
>>> Please also rename the function so that they match the method name.
>>
>> I prefer not, and it is intentionally left as is.
>>
>> This give us a very clear view what a fs is expected to do.
>
> Qu, would you please rename the individual functions?
Sure. I'll keep the fs' function names consistent with the callback names.
Especially there are already quite some maintainers wanting a consistent
pattern here.
Thanks,
Qu
>
> The NAK later just because of this is unnecessary. I will say clearly
> that I will ignore gratuitous NAKs that are premised on large scale
> rewrites that are out of scope for the problem.
>
> Here the requested rework has an acceptable scope though and we can
> sidestep the whole problem and solve it so everyone's happy.
>
Powered by blists - more mailing lists