Re: checkpatch.pl comment style warnings

2014-04-14 Thread Martin Kepplinger
Am 13.04.2014 22:49 schrieb Greg Donald:
> When I run checkpatch.pl -f, it complains about comment blocks like
> 
> /*
>  * foo
>  * bar
>  */
> 
> with "networking block comments don't use an empty /* line, use /* 
> Comment..."
> 
> But I found this: http://fr.it-usenet.org/thread/18772/41342/, which
> makes me think that particular checkpatch.pl warning should possibly
> be ignored for code not in net or drivers/net.
> 
> 1) Are there different preferred commenting styles for networking code
> versus everything else?
> 
> 2) Assuming the comment code above does need fixing, would an example
> fix be as simple as this?
> 
> /* foo
>  * bar
>  */
> 
> 3) What about the very similar comment blocks checkpatch.pl doesn't
> currently complain about, do these need fixing too?
> 
> /**
>  * foo
>  * bar
>  */
> 
> 
> Thanks.

it's not necessary to write a codingstyle patch. that's why it also may 
get rejected by
maintainers. it's necessary to write new code in the kernel's coding 
style.

in https://www.kernel.org/doc/Documentation/CodingStyle everything is 
documented:

For files in net/ and drivers/net/ the preferred style for long 
(multi-line)
comments is a little different.

/* The preferred comment style for files in net/ and drivers/net
 * looks like this.
 *
 * It is nearly the same as the generally preferred comment style,
 * but there is no initial almost-blank line.
 */

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: checkpatch.pl comment style warnings

2014-04-13 Thread Greg Freemyer


On April 13, 2014 8:04:57 PM EDT, Greg Donald  wrote:
>On Sun, Apr 13, 2014 at 4:46 PM, Greg Freemyer
> wrote:
>> In general use checkpatch.pl on code you are submitting or around
>code
>> you are already patching.
>
>But I see patches that do more than one thing get turned down every
>day.
>
>> Sending in standalone coding style patches 9 times in 10 will result
>> in a rejected patch.
>
>Why would 9/10 coding style patches be rejected simply for being
>standalone?  I thought standalone patches were preferred.

Most patches I see are sent in as a series.  A coding style patch might be 1 of 
2 and then 2 of 2 might be an actual code fix.

Most of the patch series I see tend to have 5 or more patches in the series.

So each patch should accomplish a single goal.  Code clean-up would be a single 
goal and thus a good discrete patch.

But a series that accomplished nothing beyond code cleanup is rejected by most 
of the subsystem maintainers.  They figure there are too many patches in 
progress floating around that will have to be rebased for the value of the 
cleanup to be worthwhile.

Greg

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: checkpatch.pl comment style warnings

2014-04-13 Thread Greg Donald
On Sun, Apr 13, 2014 at 4:46 PM, Greg Freemyer  wrote:
> In general use checkpatch.pl on code you are submitting or around code
> you are already patching.

But I see patches that do more than one thing get turned down every day.

> Sending in standalone coding style patches 9 times in 10 will result
> in a rejected patch.

Why would 9/10 coding style patches be rejected simply for being
standalone?  I thought standalone patches were preferred.


-- 
Greg Donald

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: checkpatch.pl comment style warnings

2014-04-13 Thread Greg Freemyer
On Sun, Apr 13, 2014 at 4:49 PM, Greg Donald  wrote:
> When I run checkpatch.pl -f, it complains about comment blocks like

In general use checkpatch.pl on code you are submitting or around code
you are already patching.

Sending in standalone coding style patches 9 times in 10 will result
in a rejected patch.

I think Greg KH recently said he would accept coding style cleanups to
drivers in the staging directory.  But even there I'm sure actual code
improvements would be preferred.

Greg (not KH)

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies