[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1332215281.7847.54.camel@joe2Laptop>
Date: Mon, 19 Mar 2012 20:48:01 -0700
From: Joe Perches <joe@...ches.com>
To: Adrian Chadd <adrian@...ebsd.org>
Cc: Jiri Slaby <jirislaby@...il.com>,
Nick Kossifidis <mickflemm@...il.com>,
"Luis R. Rodriguez" <mcgrof@....qualcomm.com>,
Bob Copeland <me@...copeland.com>,
"John W. Linville" <linville@...driver.com>,
linux-wireless@...r.kernel.org, ath5k-devel@...ts.ath5k.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH wireless-next 2/3] ath5k: Introduce _ath5k_printk to
reduce code/text
On Mon, 2012-03-19 at 20:39 -0700, Adrian Chadd wrote:
> On 18 March 2012 22:18, Joe Perches <joe@...ches.com> wrote:
> >> Otherwise compiling in debugging will cause a _lot_ of spurious
> >> register reads to occur that are then tossed. This was one of the big
> >> reasons for instability and slow performance when AH_DEBUG was
> >> enabled.
> > That doesn't make any sense in this case.
> >
> > It's either a call to printk or _ath5_printk
> > but it's still a call to a function.
>
> The FreeBSD HAL used to be like this. I changed it so it didn't
> evaluate the arguments before it figured out whether or not to do the
> (k)printf().
>
> I'm just pointing it out as you're (currently) knee deep in the
> debugging code and it may be useful for you to also think about
> implementing.
I see, thanks for the heads-up.
The no_printk function could/does eval args
and can cause those sorts of issues.
So care does need to be used.
cheers, Joe
--
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/
Powered by blists - more mailing lists