On Mon, May 17, 2021 at 02:37:10PM +0800, Xiaofei Tan wrote:
Fix coding style issues of block comments, reported by checkpatch.pl. Besides, add a period at the end of the sentenses.
Signed-off-by: Xiaofei Tan tanxiaofei@huawei.com
drivers/tty/hvc/hvc_console.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index 39018e5..a61cdf0 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -177,7 +177,8 @@ static void hvc_console_print(struct console *co, const char *b, r = cons_ops[index]->put_chars(vtermnos[index], c, i); if (r <= 0) { /* throw away characters on error
* but spin in case of -EAGAIN */
* but spin in case of -EAGAIN.*/
How is this an improvement? First, the multi-line comment style is
/* * ... */
Second, that sentence is not capitalised so why do add a period?
Third, why are you sending checkpatch.pl cleanups for files outside of staging?
Unless doing some real changes to the files in question as well this is mostly just churn and noise that makes it harder to backport fixes and do code forensics for no real gain.
Greg may disagree, but I don't think we should be encouraging this kind of patches.
Johan
Hi Johan,
Thanks for reviewing this patch.
On 2021/5/17 22:15, Johan Hovold wrote:
On Mon, May 17, 2021 at 02:37:10PM +0800, Xiaofei Tan wrote:
Fix coding style issues of block comments, reported by checkpatch.pl. Besides, add a period at the end of the sentenses.
Signed-off-by: Xiaofei Tan tanxiaofei@huawei.com
drivers/tty/hvc/hvc_console.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index 39018e5..a61cdf0 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -177,7 +177,8 @@ static void hvc_console_print(struct console *co, const char *b, r = cons_ops[index]->put_chars(vtermnos[index], c, i); if (r <= 0) { /* throw away characters on error
* but spin in case of -EAGAIN */
* but spin in case of -EAGAIN.*/How is this an improvement? First, the multi-line comment style is
/* * ... */
Yes, mostly we use this style. I can follow it if new version is needed. BTW, How about add the '/*' check into checkpatch.pl?
Second, that sentence is not capitalised so why do add a period?
How about capitalize the sentence, or just remove the period ?
Third, why are you sending checkpatch.pl cleanups for files outside of staging?
I'm sorry, Is this a rule, or kind of tradition? I've never heard of this before.
Unless doing some real changes to the files in question as well this is mostly just churn and noise that makes it harder to backport fixes and do code forensics for no real gain.
I'm not sure. But if cleanup patches have made it hard to backport fixes and do code forensics, then the code quality may not be good enough.
Greg may disagree, but I don't think we should be encouraging this kind of patches.
Johan
.
On Tue, May 18, 2021 at 12:01:22PM +0800, Xiaofei Tan wrote:
Hi Johan,
Thanks for reviewing this patch.
On 2021/5/17 22:15, Johan Hovold wrote:
On Mon, May 17, 2021 at 02:37:10PM +0800, Xiaofei Tan wrote:
Fix coding style issues of block comments, reported by checkpatch.pl. Besides, add a period at the end of the sentenses.
Signed-off-by: Xiaofei Tan tanxiaofei@huawei.com
drivers/tty/hvc/hvc_console.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index 39018e5..a61cdf0 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -177,7 +177,8 @@ static void hvc_console_print(struct console *co, const char *b, r = cons_ops[index]->put_chars(vtermnos[index], c, i); if (r <= 0) { /* throw away characters on error
* but spin in case of -EAGAIN */
* but spin in case of -EAGAIN.*/How is this an improvement? First, the multi-line comment style is
/* * ... */
Yes, mostly we use this style. I can follow it if new version is needed.
This is the preferred style outside of networking.
BTW, How about add the '/*' check into checkpatch.pl?
Checkpatch already has too many checks IMO and I'm a bit surprised that it doesn't check this already. Perhaps it's because you used the -f to run checkpatch on in-kernel code, which you should not.
Second, that sentence is not capitalised so why do add a period?
How about capitalize the sentence, or just remove the period ?
How about just leaving this unchanged?
Third, why are you sending checkpatch.pl cleanups for files outside of staging?
I'm sorry, Is this a rule, or kind of tradition? I've never heard of this before.
Many subsystems reject pure style changes unless you're also doing some real changes to the code in question. This is a good default rule, even if some maintainers may occasionally accept churn like this.
You appear to be paid to do kernel work. Why don't you start fixing bugs or help out reviewing new code instead of sending trivial patches like this? We can always need another hand.
But if all you you want is to increase your company patch count then please go work in drivers/staging where most trivial style changes are currently accepted.
Unless doing some real changes to the files in question as well this is mostly just churn and noise that makes it harder to backport fixes and do code forensics for no real gain.
I'm not sure. But if cleanup patches have made it hard to backport fixes and do code forensics, then the code quality may not be good enough.
No, that has nothing to do with code quality, it's just that you introduce noise in the logs and do pointless changes of context which makes it harder to use tools like git blame and makes backporting harder for no good reason.
Johan
Hi Johan，
On 2021/5/20 16:21, Johan Hovold wrote:
On Tue, May 18, 2021 at 12:01:22PM +0800, Xiaofei Tan wrote:
Hi Johan,
Thanks for reviewing this patch.
On 2021/5/17 22:15, Johan Hovold wrote:
On Mon, May 17, 2021 at 02:37:10PM +0800, Xiaofei Tan wrote:
Fix coding style issues of block comments, reported by checkpatch.pl. Besides, add a period at the end of the sentenses.
Signed-off-by: Xiaofei Tan tanxiaofei@huawei.com
drivers/tty/hvc/hvc_console.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c index 39018e5..a61cdf0 100644 --- a/drivers/tty/hvc/hvc_console.c +++ b/drivers/tty/hvc/hvc_console.c @@ -177,7 +177,8 @@ static void hvc_console_print(struct console *co, const char *b, r = cons_ops[index]->put_chars(vtermnos[index], c, i); if (r <= 0) { /* throw away characters on error
* but spin in case of -EAGAIN */
* but spin in case of -EAGAIN.*/How is this an improvement? First, the multi-line comment style is
/* * ... */
Yes, mostly we use this style. I can follow it if new version is needed.
This is the preferred style outside of networking.
BTW, How about add the '/*' check into checkpatch.pl?
Checkpatch already has too many checks IMO and I'm a bit surprised that it doesn't check this already. Perhaps it's because you used the -f to run checkpatch on in-kernel code, which you should not.
Second, that sentence is not capitalised so why do add a period?
How about capitalize the sentence, or just remove the period ?
How about just leaving this unchanged?
OK And I will keep the patch 8/9, and combine space issues into one new patch, and remove the others.
Third, why are you sending checkpatch.pl cleanups for files outside of staging?
I'm sorry, Is this a rule, or kind of tradition? I've never heard of this before.
Many subsystems reject pure style changes unless you're also doing some real changes to the code in question. This is a good default rule, even if some maintainers may occasionally accept churn like this.
You appear to be paid to do kernel work. Why don't you start fixing bugs or help out reviewing new code instead of sending trivial patches like this? We can always need another hand.
But if all you you want is to increase your company patch count then please go work in drivers/staging where most trivial style changes are currently accepted.
Unless doing some real changes to the files in question as well this is mostly just churn and noise that makes it harder to backport fixes and do code forensics for no real gain.
I'm not sure. But if cleanup patches have made it hard to backport fixes and do code forensics, then the code quality may not be good enough.
No, that has nothing to do with code quality, it's just that you introduce noise in the logs and do pointless changes of context which makes it harder to use tools like git blame and makes backporting harder for no good reason.
Johan
.
On Thu, May 20, 2021 at 09:21:25PM +0800, Xiaofei Tan wrote:
Checkpatch already has too many checks IMO and I'm a bit surprised that it doesn't check this already. Perhaps it's because you used the -f to run checkpatch on in-kernel code, which you should not.
Second, that sentence is not capitalised so why do add a period?
How about capitalize the sentence, or just remove the period ?
How about just leaving this unchanged?
OK And I will keep the patch 8/9, and combine space issues into one new patch, and remove the others.
Yeah, 8/9 is arguably a fix even if it's for a very minor issue (repeated words in a comment).
It doesn't look like any of the white space issues are worth fixing, though. Such pedantry can usually be addressed when the code in question is being modified for other reasons.
Johan
Hi Johan,
On 2021/5/20 21:52, Johan Hovold wrote:
On Thu, May 20, 2021 at 09:21:25PM +0800, Xiaofei Tan wrote:
Checkpatch already has too many checks IMO and I'm a bit surprised that it doesn't check this already. Perhaps it's because you used the -f to run checkpatch on in-kernel code, which you should not.
Second, that sentence is not capitalised so why do add a period?
How about capitalize the sentence, or just remove the period ?
How about just leaving this unchanged?
OK And I will keep the patch 8/9, and combine space issues into one new patch, and remove the others.
Yeah, 8/9 is arguably a fix even if it's for a very minor issue (repeated words in a comment).
It doesn't look like any of the white space issues are worth fixing, though. Such pedantry can usually be addressed when the code in question is being modified for other reasons.
OK, it is reasonable. thanks.
Johan
.
On Thu, 2021-05-20 at 10:21 +0200, Johan Hovold wrote:
On Tue, May 18, 2021 at 12:01:22PM +0800, Xiaofei Tan wrote:
On 2021/5/17 22:15, Johan Hovold wrote:
On Mon, May 17, 2021 at 02:37:10PM +0800, Xiaofei Tan wrote:
Fix coding style issues of block comments, reported by checkpatch.pl. Besides, add a period at the end of the sentenses.
[]
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
[]
@@ -177,7 +177,8 @@ static void hvc_console_print(struct console *co, const char *b, r = cons_ops[index]->put_chars(vtermnos[index], c, i); if (r <= 0) { /* throw away characters on error
* but spin in case of -EAGAIN */
* but spin in case of -EAGAIN.*/How is this an improvement? First, the multi-line comment style is
/* * ... */
Yes, mostly we use this style. I can follow it if new version is needed.
This is the preferred style outside of networking.
BTW, How about add the '/*' check into checkpatch.pl?
Checkpatch already has too many checks IMO
I sometimes agree. What checkpatch messages do you think are excessive?
and I'm a bit surprised that it doesn't check this already. Perhaps it's because you used the -f to run checkpatch on in-kernel code, which you should not.
Likely not. If it was run on a suggested patch, checkpatch doesn't emit many messages on unmodified patch context lines. And it shouldn't.
it's just that you introduce noise in the logs and do pointless changes of context which makes it harder to use tools like git blame and makes backporting harder for no good reason.
Pretty pointless metric IMO. Context changes in comments are mostly harmless. IMO: backporting of these sorts non-bug fix changes is done _far_ too often.
On Thu, May 20, 2021 at 08:21:39AM -0700, Joe Perches wrote:
On Thu, 2021-05-20 at 10:21 +0200, Johan Hovold wrote:
On Tue, May 18, 2021 at 12:01:22PM +0800, Xiaofei Tan wrote:
On 2021/5/17 22:15, Johan Hovold wrote:
How is this an improvement? First, the multi-line comment style is
/* * ... */
Yes, mostly we use this style. I can follow it if new version is needed.
This is the preferred style outside of networking.
BTW, How about add the '/*' check into checkpatch.pl?
Checkpatch already has too many checks IMO
I sometimes agree. What checkpatch messages do you think are excessive?
The "unsigned" -> "unsigned int" one comes to mind (at least when running with -f).
Most of the questionable ones are probably hidden behind --subjective, but due to the unfortunate alias of that switch as --strict, people don't get the message to use their own judgement and instead think they'll get a gold star for "full compliance".
So my issue isn't so much which checkpatch itself rather than with how it is being used and promoted, for example, to introduce aspiring developers to kernel development in staging.
It's a great tool to run on your own patches before submission (as was originally intended judging by the apt name), but if I could change something I'd drop the --strict alias for the --subjective checks and disable that switch for staging.
Perhaps also add a warning or similar when running with -f on in-tree code outside of staging.
and I'm a bit surprised that it doesn't check this already. Perhaps it's because you used the -f to run checkpatch on in-kernel code, which you should not.
Likely not. If it was run on a suggested patch, checkpatch doesn't emit many messages on unmodified patch context lines. And it shouldn't.
Right, but here it appears to have been run using -f on in-tree code.
You could still check for this when adding new comments, and perhaps it already does.
it's just that you introduce noise in the logs and do pointless changes of context which makes it harder to use tools like git blame and makes backporting harder for no good reason.
Pretty pointless metric IMO. Context changes in comments are mostly harmless.
This isn't just about comment changes but the whole array of white-space shifting and other pendantry. And also reformatted comments makes it harder to do code forensics.
IMO: backporting of these sorts non-bug fix changes is done _far_ too often.
I have yet to see AUTOSEL pick up white-space cleanups but there are certainly a few non-bug-fix patches currently being backported.
Johan
-
Joe Perches -
Johan Hovold -
Xiaofei Tan