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] [day] [month] [year] [list]
Date: Wed, 05 Jun 2024 14:13:17 +0300
From: Kalle Valo <kvalo@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: "Nemanov, Michael" <michael.nemanov@...com>,  Johannes Berg
 <johannes.berg@...el.com>,  Breno Leitao <leitao@...ian.org>,  Justin
 Stitt <justinstitt@...gle.com>,  Kees Cook <keescook@...omium.org>,
  linux-wireless@...r.kernel.org,  linux-kernel@...r.kernel.org,  Sabeeh
 Khan <sabeeh-khan@...com>
Subject: Re: [PATCH 08/17] Add main.c

Krzysztof Kozlowski <krzk@...nel.org> writes:

>>>>> +u32 cc33xx_debug_level = DEBUG_NO_DATAPATH;
>>>>>
>>>> Why this is global? Why u32? Why global variable is defined at the end
>>>> of the file?!?!
>>>  
>>> cc33xx_debug_level together with cc33xx_debug/info/error() macros is how
>>> all traces were done in drivers/net/wireless/ti/wlcore/ (originally was
>>> wl1271_debug/info etc.)
>>> It enables / disables traces without rebuilding or even reloading which
>>> is very helpful for remote support. These macros map to dynamic_pr_debug
>>> / pr_debug. I saw similar wrappers in other wireless drivers (ath12k).
>>> This is also why there are plenty of cc33xx_debug() all over the code,
>>> most are silent by default.
>> 
>> Any more thoughts on debug traces? I'll remove all trivial function 
>> entry / exit traces as Krzysztof requested. Is it OK to keep other 
>> cc33xx_debug() calls which will be off by default?
>
> Sorry, I don't see the point. Dynamic debug gives you debug control. You
> just added orthogonal code to existing debug infrastructure, so as far
> as I am concerned, this should be dropped in favor of standard debugging
> calls.

I think most wireless drivers have this kind of debug level parameter,
for example debug_level in iwlwifi or debug_mask in ath12k. Our problem
with the dynamic debug framework is that it's either too fine grained
(ie. per line) or too coarse (per file), but in wireless we usually want
to have some kind of per functionality level debugging as well. For
example, to show only management frame transmissions, certain firmware
interface commands and so on.

A long time ago there was a discussion about extending dynamic debug
framework but not sure if that ever happened.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ