[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5443DF6A-0154-47FD-8347-DE3464A1CF03@vmware.com>
Date: Sun, 18 Sep 2022 17:43:17 +0000
From: Nadav Amit <namit@...are.com>
To: Randy Dunlap <rdunlap@...radead.org>,
Jilin Yuan <yuanjilin@...rlc.com>
CC: Pv-drivers <Pv-drivers@...are.com>, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: fix repeated words in comments
On Sep 18, 2022, at 8:08 AM, Randy Dunlap <rdunlap@...radead.org> wrote:
> ⚠ External Email
>
> On 9/18/22 03:01, Jilin Yuan wrote:
>> Delete the redundant word 'on'.
>>
>> Signed-off-by: Jilin Yuan <yuanjilin@...rlc.com>
>> ---
>> drivers/misc/vmw_balloon.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
>> index 61a2be712bf7..c2e774f68133 100644
>> --- a/drivers/misc/vmw_balloon.c
>> +++ b/drivers/misc/vmw_balloon.c
>> @@ -736,7 +736,7 @@ static int vmballoon_handle_one_result(struct vmballoon *b, struct page *page,
>> * @p: pointer to where the page struct is returned.
>> *
>> * Following a lock or unlock operation, returns the status of the operation for
>> - * an individual page. Provides the page that the operation was performed on on
>> + * an individual page. Provides the page that the operation was performed on
>
> This would make more sense to me: (s/on on/on in/)
Yes, your version, Randy, is the right one. Thanks Randy and Jilin.
Jilin, while your work is highly appreciated, looking at lkml shows that you
put quite an effort (100s of patches) into the duplicate words problem.
Since 2020 checkpatch warns if you try to push a patch with repeated words.
So all of these mistakes will eventually go away as people make
adjacent/overlapping changes. Understanding the meaning of text with
repeated words is not that hard. Some might argue that polluting the git
history for this purpose is not helping.
Now it is hard to get into the kernel, and making trivial patches is a good
way to start. However, I think it is more helpful if you take one or few
subsystems and focus on fixing them, and thereby gaining deeper
understanding of their code. It would also allow you to introduce yourself
to the maintainers. There are other tasks you can consider, such as more
significant checkpatch warnings, there are bug reports of syzbot you can
look into, etc. As it is right now, it seems that the main benefit from
these trivial patches is increasing the number of patches you submitted to
the kernel.
Again, thank you Jilin.
Powered by blists - more mailing lists