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`.
