Hi Ingo,
On 04/27/2018 01:00 PM, tip-bot for Ingo Molnar wrote:
Commit-ID: 5f26c50143f58f256535bee8d93a105f36d4d2da
Gitweb: https://git.kernel.org/tip/5f26c50143f58f256535bee8d93a105f36d4d2da
Author: Ingo Molnar <mingo@xxxxxxxxxx>
AuthorDate: Fri, 27 Apr 2018 11:54:40 +0200
Committer: Ingo Molnar <mingo@xxxxxxxxxx>
CommitDate: Fri, 27 Apr 2018 12:42:04 +0200
x86/bpf: Clean up non-standard comments, to make the code more readable
So by chance I looked into x86 assembly in arch/x86/net/bpf_jit_comp.c and
noticed the weird and inconsistent comment style it mistakenly learned from
the networking code:
/* Multi-line comment ...
* ... looks like this.
*/
Fix this to use the standard comment style specified in Documentation/CodingStyle
and used in arch/x86/ as well:
/*
* Multi-line comment ...
* ... looks like this.
*/
Also, to quote Linus's ... more explicit views about this:
> But no, the networking code picked *none* of the above sane formats.
> Instead, it picked these two models that are just half-arsed
> shit-for-brains:
>
> (no)
> /* This is disgusting drug-induced
> * crap, and should die
> */
>
> (no-no-no)
> /* This is also very nasty
> * and visually unbalanced */
>
> Please. The networking code actually has the *worst* possible comment
> style. You can literally find that (no-no-no) style, which is just
> really horribly disgusting and worse than the otherwise fairly similar
> (d) in pretty much every way.
Also improve the comments and some other details while at it:
- Don't mix same-line and previous-line comment style on otherwise
identical code patterns within the same function,
- capitalize 'BPF' and x86 register names consistently,
- capitalize sentences consistently,
- instead of 'x64' use 'x86-64': x64 is a Microsoft specific term,
- use more consistent punctuation,
- use standard coding style in macros as well,
- fix typos and a few other minor details.
Consistent coding style is not optional, at least in arch/x86/.
No change in functionality.
Thanks for the cleanup, looks fine to me!
( In case this commit causes conflicts with pending development code
I'll be glad to help resolve any conflicts! )
Any objections if we would simply route this via bpf-next tree, otherwise
this will indeed cause really ugly merge conflicts throughout the JIT with
pending work.