All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Daiker <daikerjohn@gmail.com>
To: Michael Buesch <mb@bu3sch.de>
Cc: stefano.brivio@polimi.it, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] b43: reduce checkpatch.pl errors
Date: Fri, 17 Oct 2008 14:36:36 -0700	[thread overview]
Message-ID: <48F90564.3040301@gmail.com> (raw)
In-Reply-To: <200810172302.38127.mb@bu3sch.de>

Michael,

Thanks for the feedback.  Bob Copeland had mentioned on a different 
patch that I compare the binaries before and after a patch.  I will be 
sure to do this on the patch rework.  Further comments inline.

Michael Buesch wrote:
> On Friday 17 October 2008 21:16:09 John Daiker wrote:
>   
>> A few changes to reduce checkpatch.pl errors in the b43 driver.  For the 
>> most part, I only fixed cosmetic things, and left the actual 'code flow' 
>> untouched (hopefully)!
>>
>> Diff is against wireless-testing HEAD.
>>
>> Signed-off-by: John Daiker <daikerjohn@gmail.com>
>>
>> ---
>>
>>
>>
>>     
>
> Looks good, except these:
>
>   
>> -		if (1 /*FIXME: the last PSpoll frame was sent successfully */ )
>> +		if (1) {
>> +			/*FIXME: the last PSpoll frame was sent successfully */
>>     
>
> Makes it a lot less obvious what the comment is talking about.
> Please leave this untouched.
>   
How about this:

-		if (1 /*FIXME: the last PSpoll frame was sent successfully */ )
+		if (1) {  /*FIXME: the last PSpoll frame was sent successfully */

or this?

-		if (1 /*FIXME: the last PSpoll frame was sent successfully */ )
+		if (1) /*FIXME: the last PSpoll frame was sent successfully */ {


I'm just not a fan of putting the comment inside the if conditional.
Your argument about losing the precise meaning of the comment is 
understood, but I think there is a middleground here. I would hope that 
any 'if (1)' line would immediately raise the 'look for a comment' flag 
in someone's brain. :P
>> -		if (!gphy->aci_enable && 1 /*TODO: not scanning? */ ) {
>> -			if (0 /*TODO: bunch of conditions */ ) {
>> +		if (!gphy->aci_enable && 1) {
>> +			/* TODO: not scanning? */
>> +			if (0) {
>> +				/*TODO: bunch of conditions */
>>     
>
> Same here.
>
> There are probably more of these. I didn't check the whole patch.
>
>   
>> -	//TODO
>> +	/* TODO */
>>     
>
> Well, that's only generating noise in git and results in merge conflicts
> and stuff. I do only use // style comments for temporary comments.
> IMO this is OK.
>   
I'll strip these out of the next patch.  I agree this is a weird rule, 
but checkpatch.pl did all the work.  I'll put more brainpower behind the 
next patch, haha.
>   
>> -char * b43_rfkill_led_name(struct b43_wldev *dev)
>> +char *b43_rfkill_led_name(struct b43_wldev *dev)
>>     
>
> Well, in my opinion it looks bad to glue the * to the function name.
> The pointer * is not related to the function name, but to the return value.
>
> (Note that for variable definitions this is different and I agree that
> we should put the * in front of the variable name without spaces)
>
> Well, but I'm not going to create a flamewar for this.
> If this is kernel coding style, feel free to change the code.
>   
I'm certainly not trying to start a flamewar, either, so thanks for 
keeping the torches at bay! :)  AFAIK, this is accepted (and preferred?) 
kernel style, so it will be included in the updated patch.  At least 
until I see more vigorous pushback.
>
> One additional thing I'd like you to do.
> Do a b43 compile before and after applying the patch.
> Keep the b43.ko files for both runs and do an md5sum on them.
> Add the results to the commit log. The sums _must_ match.
> If they don't, please send the changes that change the actual
> binary code in seperate patches.
>   
Will do this next time with updated patch, among other things.

Thanks,
JD

  reply	other threads:[~2008-10-17 21:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-17 19:16 [PATCH] b43: reduce checkpatch.pl errors John Daiker
2008-10-17 21:02 ` Michael Buesch
2008-10-17 21:36   ` John Daiker [this message]
2008-10-17 21:45     ` Michael Buesch
2008-10-17 21:58       ` John Daiker
2008-10-17 22:22         ` Michael Buesch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48F90564.3040301@gmail.com \
    --to=daikerjohn@gmail.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mb@bu3sch.de \
    --cc=stefano.brivio@polimi.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.