Re: [ath5k-devel] [PATCH wireless-next 2/3] ath5k: Introduce _ath5k_printk to reduce code/text
On 18 March 2012 22:18, Joe Perches j...@perches.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. adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH wireless-next 2/3] ath5k: Introduce _ath5k_printk to reduce code/text
Hi, So the reason this is a macro in the FreeBSD HAL is so that the args aren't evaluated unless the level (or debug bitmap in my case) fires off. 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. Adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] [PATCH wireless-next 2/3] ath5k: Introduce _ath5k_printk to reduce code/text
On Sun, 2012-03-18 at 21:36 -0700, Adrian Chadd wrote: Hi, Hi Adrian. So the reason this is a macro in the FreeBSD HAL is so that the args aren't evaluated unless the level (or debug bitmap in my case) fires off. 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. +void __printf(3, 4) +_ath5k_printk(const struct ath5k_hw *ah, const char *level, + const char *fmt, ...); + #define ATH5K_PRINTK(_sc, _level, _fmt, ...) \ - printk(_level pr_fmt(%s%s _fmt), \ - ((_sc) (_sc)-hw) ? wiphy_name((_sc)-hw-wiphy) : , \ - ((_sc) (_sc)-hw) ? : : ,\ - ##__VA_ARGS__) + _ath5k_printk(_sc, _level, _fmt, ##__VA_ARGS__) If there are level/mask tests to macros that are used to call ATH5K_PRINTK, that still works. As far as I can tell, there aren't any uses of macros like that. cheers, Joe ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
