linux-kernel - Re: [PATCH] net: mac80211: tx.c: be sure of 'sdata->vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 01 Dec 2013 19:50:27 +0800
From:	Chen Gang <gang.chen.5i5j@...il.com>
To:	Johannes Berg <johannes@...solutions.net>
CC:	Joe Perches <joe@...ches.com>,
	"John W. Linville" <linville@...driver.com>,
	rkuo <rkuo@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	linux-wireless@...r.kernel.org, netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] net: mac80211: tx.c: be sure of 'sdata->vif.type' must
 be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case

On 12/01/2013 05:37 PM, Johannes Berg wrote:
> On Sun, 2013-12-01 at 07:48 +0800, Chen Gang wrote:
> 
>> If ieee80211_subif_start_xmit() is not performance sensitive (I guess
>> so), we can use some short static functions instead of some code blocks
>> within ieee80211_subif_start_xmit().
>>
>>  - ieee80211_subif_start_xmit() is a long function (600+ lines).
>>
>>  - use short static function can share some code.
>>
>>  - if code can be shared, the work flow can be more clearer too (don't
>>    need fall-through or goto).
> 
> Frankly, I'm getting tired of discussing this. Please don't try to
> rewrite this code until you've understood it. You suggesting that
> "start_xmit()" isn't a performance sensitive function makes me realize
> you haven't even tried.
> 

OK, thank you for "you are getting tired ...". Please help try when you
have time.  :-)

No I didn't try -- so use 'if' and 'guess' for discussing.

Hmm... if it is performance sensitive:

 - use static function instead of some code block and try to share them.
   it adds additional instructions, but can shrink binary code size.
   if the performance is acceptable, it is the best way to me.

 - else (1st way not acceptable), use macro instead of static function.
   it expends binary code size, but can save some instructions.
   if the performance is acceptable, it is the acceptable way to me.

 - If neither of static function nor macro are acceptable,
   I still prefer to use 'goto' instead of 'fall-through'.
   that can let all compilers feel well, and can not feel any strange.

     normally, when prev case uses fall-through,
     it need be sure of next case need not notice about it (prev case).
     or it will make a little strange for readers when read next case.


Welcome any suggestions or completions.

Thanks.
-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/