[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8822d84d-eedc-4b3b-a6c0-4ccef4c0cecc@huaweicloud.com>
Date: Thu, 22 May 2025 16:02:39 +0800
From: Zizhi Wo <wozizhi@...weicloud.com>
To: Amir Goldstein <amir73il@...il.com>, Zizhi Wo <wozizhi@...weicloud.com>
Cc: viro@...iv.linux.org.uk, brauner@...nel.org, jack@...e.cz,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
yangerkun@...wei.com
Subject: Re: [PATCH] fs: Rename the parameter of mnt_get_write_access()
在 2025/5/22 15:41, Amir Goldstein 写道:
> On Thu, May 22, 2025 at 3:02 AM Zizhi Wo <wozizhi@...weicloud.com> wrote:
>>
>> Hello!
>>
>> There are currently two possible approaches to this patch.
>> The first is to directly change the declaration, which would be
>> straightforward and involve minimal modifications.
>>
>> However, per Al Viro's suggestion — that "mnt for vfsmount, m for mount"
>> is an informal convention. This is in line with what the current
>> patch does, although I understand Jan Kara might feel that the scope of
>> the changes is a bit large.
>>
>> I would appreciate any suggestions or guidance on how to proceed. So
>> friendly ping...
>
> Hi Zizhi,
>
> I guess you are not familiar with kernel lingo so I will translate:
> "...so I'd say go for it if there had been any change in the function
> in question. Same as with coding style, really...
>
> It means that your change is correct, but maintainers are
> not interested in taking "style only" changes because it
> creates undesired git history noise called "churn".
Thank you for your patient explanation! I'm indeed a newcomer to the
Linux kernel. Now I understand what everyone means.
>
> Should anyone be going to make logic changes in
> mnt_get_write_access() in the future, the style change
> can be applied along in the same patch.
>
> One observation I have is -
> If this was the only case that deviates from the standard
> the change might have been justified.
>>>From a quick grep, I see that the reality in the code is very far
> from this standard.
Yes, I noticed that as well. However, for consistency with the later use
of mnt_put_write_access(), I chose to go with the modification in this
patch...
Thanks,
Zizhi Wo
>
> FWIW, wholeheartedly I agree that the ambiguity of the type of
> an 'mnt' arg is annoying, but IMO 'm' is not making that very clear.
> To me, 'mount' arg is very clear when it appears in the code
>
> Thanks,
> Amir.
>
Powered by blists - more mailing lists