Re: Clarification for source code formatting around jump labels

2016-09-04 Thread Daniel Borkmann 

On 09/04/2016 03:50 PM, SF Markus Elfring wrote:

I am just curious on how much further software development "fun" the recent 
update
by a topic like "CodingStyle: Clarify and complete chapter 7" will trigger.


I don't want to drag this thread onwards for (way) too long, but clearly "it is
advised to indent labels with a single space (not tab)" (from diff in above 
commit)


How do you think about the reason (which you omitted from your quotation) for 
this advice?

“…,
so that "diff -p" does not confuse labels with functions.
…”


Yep, since this recently came up in a different thread as well, please
see here, for example:

  http://patchwork.ozlabs.org/patch/664966/


doesn't really reflect the majority of kernel practice we have in-tree today and
actually rather adds more confusion than any clarification whatsoever:

   $ git grep -n "^\ [a-z_]*:" -- '*.[ch]' | wc -l
   4919
   $ git grep -n "^[a-z_]*:" -- '*.[ch]' | wc -l
   54686


So there is a mixture already.


[...]

In which ways would you prefer that the style specifications should be
clarified further?

Where should source code become more consistent?


It would likely make sense to document that git config mentioned in the
link above as a recommendation for that paragraph, and stick with what
is used in the vast majority of cases already, meaning no leading space
before labels.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Clarification for source code formatting around jump labels

2016-09-04 Thread SF Markus Elfring 
>> I am just curious on how much further software development "fun" the recent 
>> update
>> by a topic like "CodingStyle: Clarify and complete chapter 7" will trigger.
> 
> I don't want to drag this thread onwards for (way) too long, but clearly "it 
> is
> advised to indent labels with a single space (not tab)" (from diff in above 
> commit)

How do you think about the reason (which you omitted from your quotation) for 
this advice?

“…,
so that "diff -p" does not confuse labels with functions.
…”


> doesn't really reflect the majority of kernel practice we have in-tree today 
> and
> actually rather adds more confusion than any clarification whatsoever:
> 
>   $ git grep -n "^\ [a-z_]*:" -- '*.[ch]' | wc -l
>   4919
>   $ git grep -n "^[a-z_]*:" -- '*.[ch]' | wc -l
>   54686

So there is a mixture already.


> A CodingStyle document should document what's regarded as a general consensus 
> of
> kernel coding practices, and thus should represent the /majority/ of coding 
> style,
> which (if I didn't screw up my git-grep line completely)

1. Is the used character class specification complete in the shown regular 
expression?

2. I guess that you should use the regex operator "plus" (instead of the 
asterisk).

3. Would you like to try another source code analysis out which can be a bit 
safer
   with the usage of the semantic patch language?


> above 9% does not really reflect at all.

How tolerant are you for using an extra space character before the identifier 
for
a jump label?


> So, new folks starting with kernel hacking reading this are rather misguided,
> and code-wise it just adds up to have more inconsistencies from new patches,
> or worse, have noisy patches (like this one) flying around that try to
> brute-force everything into this advice.

In which ways would you prefer that the style specifications should be
clarified further?

Where should source code become more consistent?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

2016-09-04 Thread Daniel Borkmann 

On 09/04/2016 09:20 AM, SF Markus Elfring wrote:

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51


[ + Jonathan for above commit in linux-next ]


You seem to lack understanding of the difference between absolute
requirements and "advice".

As Sparc maintainer I can choose to not take this "advice",
and I so choose to do so.


Your conclusion can be fine in principle.

I am just curious on how much further software development "fun" the recent 
update
by a topic like "CodingStyle: Clarify and complete chapter 7" will trigger.


I don't want to drag this thread onwards for (way) too long, but clearly "it is
advised to indent labels with a single space (not tab)" (from diff in above 
commit)
doesn't really reflect the majority of kernel practice we have in-tree today and
actually rather adds more confusion than any clarification whatsoever:

  $ git grep -n "^\ [a-z_]*:" -- '*.[ch]' | wc -l
  4919
  $ git grep -n "^[a-z_]*:" -- '*.[ch]' | wc -l
  54686

A CodingStyle document should document what's regarded as a general consensus of
kernel coding practices, and thus should represent the /majority/ of coding 
style,
which (if I didn't screw up my git-grep line completely) above 9% does not 
really
reflect at all. So, new folks starting with kernel hacking reading this are 
rather
misguided, and code-wise it just adds up to have more inconsistencies from new
patches, or worse, have noisy patches (like this one) flying around that try to
brute-force everything into this advice.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

2016-09-04 Thread SF Markus Elfring 
> It's not because I find improvements "uncomfortable", but rather it's
> because your changes are not seen as improvements in the first place.

What is your software development opinion for the update step
"[1/4] sparc: bpf_jit: Use kmalloc_array() in bpf_jit_compile()"
from this small patch series?

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

2016-09-04 Thread SF Markus Elfring 
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51
> 
> You seem to lack understanding of the difference between absolute
> requirements and "advice".
> 
> As Sparc maintainer I can choose to not take this "advice",
> and I so choose to do so.

Your conclusion can be fine in principle.

I am just curious on how much further software development "fun" the recent 
update
by a topic like "CodingStyle: Clarify and complete chapter 7" will trigger.


> If you want to be completely ignored by me,

I hope that this action does not need to happen.


> then keep arguing the way you are right now.

I guess that I will stumble on more software improvement opportunities
you find harder to become comfortable with.

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

2016-09-04 Thread David Miller 
From: SF Markus Elfring 
Date: Sun, 4 Sep 2016 09:20:55 +0200

> I guess that I will stumble on more software improvement opportunities
> you find harder to become comfortable with.

Improvement is a matter of opinion.  So your statement assumes that
your changes are an improvement, and everyone in this thread clearly
disagrees with that.

This is why everything you are doing here is so irritating.

It's not because I find improvements "uncomfortable", but rather it's
because your changes are not seen as improvements in the first place.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

2016-09-04 Thread David Miller 
From: SF Markus Elfring 
Date: Sun, 4 Sep 2016 08:50:20 +0200

>>> NAK, just noise.
>> 
>> And frankly I hate that leading space.
> 
> Would you like to comment the recent update of the document "CodingStyle" any 
> more?
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51

You seem to lack understanding of the difference between absolute
requirements and "advice".

As Sparc maintainer I can choose to not take this "advice", and I so
choose to do so.

If you want to be completely ignored by me, then keep arguing the way
you are right now.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

2016-09-04 Thread SF Markus Elfring 
>> NAK, just noise.
> 
> And frankly I hate that leading space.

Would you like to comment the recent update of the document "CodingStyle" any 
more?
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html