linux-wireless.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).