From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <johannes@sipsolutions.net>
Received: from sipsolutions.net (s3.sipsolutions.net [5.9.151.49])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by lists.bufferbloat.net (Postfix) with ESMTPS id 589F73B25D
 for <make-wifi-fast@lists.bufferbloat.net>;
 Thu,  1 Sep 2016 05:27:03 -0400 (EDT)
Received: by sipsolutions.net with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87)
 (envelope-from <johannes@sipsolutions.net>)
 id 1bfOGz-0003Le-A8; Thu, 01 Sep 2016 11:27:01 +0200
Message-ID: <1472722020.9608.3.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= <toke@toke.dk>
Cc: make-wifi-fast@lists.bufferbloat.net, linux-wireless@vger.kernel.org
Date: Thu, 01 Sep 2016 11:27:00 +0200
In-Reply-To: <8760qgugb0.fsf@toke.dk>
References: <20160824162015.29933-1-toke@toke.dk>
 <20160830131548.6014-1-toke@toke.dk>
 <1472677599.5470.13.camel@sipsolutions.net> <87inug81vo.fsf@toke.dk>
 <1472718860.4249.0.camel@sipsolutions.net> <8737lk816p.fsf@toke.dk>
 <1472720848.9608.1.camel@sipsolutions.net> <8760qgugb0.fsf@toke.dk>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.20.4-1+b1 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [Make-wifi-fast] [PATCH v4] mac80211: Move reorder-sensitive TX
 handlers to after TXQ dequeue.
X-BeenThere: make-wifi-fast@lists.bufferbloat.net
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: <make-wifi-fast.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/make-wifi-fast>,
 <mailto:make-wifi-fast-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/make-wifi-fast>
List-Post: <mailto:make-wifi-fast@lists.bufferbloat.net>
List-Help: <mailto:make-wifi-fast-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/make-wifi-fast>,
 <mailto:make-wifi-fast-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2016 09:27:03 -0000


> Yeah, was going to do that anyway. But since I'm touching the code
> anyway, this might be an opportunity to avoid constructs like this:
> 
> if (!invoke_tx_handlers(tx))
>   /* continue sending the packet */
> 
> Most other succeed/fail functions seem to be of type bool, so it
> would help consistency as well. Unless there is some particular
> reason why this function happens to be using 0 to indicate success?
> 

It's just convention in the kernel, really.

IMHO if a function has a bool return value it should be have a more
expressive name that indicates better what's going on, like e.g.

bool ieee80211_is_radar_required(...);

but of course that's not always done.

johannes