[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB3PR10MB6835DDFE9086DAC4B01C7508E8A9A@DB3PR10MB6835.EURPRD10.PROD.OUTLOOK.COM>
Date: Tue, 7 Nov 2023 21:32:51 +0530
From: Yuran Pereira <yuran.pereira@...mail.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: linux-bluetooth@...r.kernel.org, johan.hedberg@...il.com,
marcel@...tmann.org, linux-kernel@...r.kernel.org,
luiz.dentz@...il.com,
linux-kernel-mentees@...ts.linuxfoundation.org
Subject: Re: [PATCH 2/2] Bluetooth: Replaces printk with pr_debug in bt_dbg
Hello Greg,
On Tue, Nov 07, 2023 at 07:31:27AM +0100, Greg KH wrote:
>
> You might have just changed the functionality here, are you SURE this is
> identical to the original code? How was it tested?
>
> I'm not saying this is a bad idea to do, just be aware of the
> consequences for this change and document it properly (hint, the
> changelog does not document the user-visible change that just happened.)
>
> Note, pr_debug() is NOT identical to printk(), look at the source for
> the full details.
>
Thank you for the heads-up.
Yes, you're right.
I just took another look and it seems that using pr_debug here
does defeat the purpose of bt_dbg which was created for situations
where `DYNAMIC_DEBUG` and `DEBUG` are disabled.
The likely equivalent would have been `pr_devel` but that also
depends on `DEBUG`.
Do you think that a new `pr_devel_uncond` like the one below
(only to be used in exceptional scenarios) would be a good idea?
```
#define pr_devel_uncond(fmt, ...) \
printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
```
This would neither depend on `DYNAMIC_DEBUG` nor on `DEBUG`.
Powered by blists - more mailing lists