On Fri, Apr 28, 2017 at 3:14 PM, Dan Williams <dan.j.williams(a)intel.com> wrote:
On Fri, Apr 28, 2017 at 3:07 PM, Joe Perches <joe(a)perches.com>
wrote:
> On Fri, 2017-04-28 at 14:52 -0700, Dan Williams wrote:
>> On Fri, Apr 28, 2017 at 2:49 PM, Joe Perches <joe(a)perches.com> wrote:
>> > On Fri, 2017-04-28 at 14:28 -0700, Dan Williams wrote:
>> > > More than one driver has worked around the fact that
>> > > print_hex_dump_debug() requires CONFIG_DYNAMIC_DEBUG=y to build.
>> >
>> > No it doesn't. builds work fine. Output is restricted.
>> >
>> > > Provide a dynamic_hex_dump() so that drivers that want the extra
debugging to be
>> > > turned off in the CONFIG_DYNAMIC_DEBUG=n can use dynamic_hex_dump()
>> > > directly.
>> >
>> > I think the concept is unnecessary
>> > .
>> > Just use print_hex_dump with KERN_DEBUG.
>>
>> No, we don't want any possibility of output in the
>> CONFIG_DYNAMIC_DEBUG=n case. This is extra debug that only makes sense
>> in the CONFIG_DYNAMIC_DEBUG case.
>
> No, that doesn't work the same.
>
> Look at your conversion of drivers/acpi/nfit/core.c
>
> dev_dbg outputs always when DEBUG is defined and
> optionally outputs when CONFIG_DYNAMIC_DEBUG is enabled.
Right, that's what I want dev_dbg() to output at KERN_DEBUG level
always and the hexdump only in the dynamic case.
Joe, I'm trying to understand your objection. What you are proposing
is that the debug output is present at the KERN_DEBUG level in the
CONFIG_DYNAMIC_DEBUG=n case and that's not what either use case wants.
What breaks by letting users call dynamic_hex_dump() directly?