Re: [PATCH] fs: Rename the parameter of mnt_get_write_access()

[Zizhi Wo <wozizhi@huaweicloud.com>]

在 2025/5/22 15:41, Amir Goldstein 写道:
> On Thu, May 22, 2025 at 3:02 AM Zizhi Wo <wozizhi@huaweicloud.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.
>