lkml.org 
[lkml]   [2022]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC][PATCH] ACPI: tracing: Have ACPI debug go to tracing ring buffer
On Thu, Dec 15, 2022 at 2:11 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 15 Dec 2022 18:45:37 +0000
> Joel Fernandes <joel@joelfernandes.org> wrote:
>
> > Wouldn't it be better to also check trace_acpi_print_enabled() here in the
> > else if() condition, along with IS_ENABLED()? That way if the CONFIG is
> > enabled but the tracepoint is not enabled, at least the messages will go to
> > dmesg instead of skipped.
>
> I really don't want that. This was purposely done to be mutually exclusive.
> The reason I added this in the first place, is because too much enabled
> will render the system useless if printk() is used.
>
> After boot up, if I had enabled all debug events and then I were to disable
> the acpi tracepoint, it will likely render the system useless again if it
> were to switch over to printk.

Ok, sure. I see where you were going. So you want no debugging
messages at all if the trace event is disabled. That's fine with me. I
would also add a note about the need to enable the specific trace
event, in the Kconfig message and/or the Documentation. Otherwise, you
might get someone say, "hey I enabled the CONFIG option but I see
nothing in the trace buffer".

Another approach could be to always enable the trace event by default,
if the CONFIG is turned on. Or do a printk() telling the user about
the event to enable, so they know why their trace buffer is empty.

Up to you and the ACPI maintainers. ;-)

thanks,

- Joel

\
 
 \ /
  Last update: 2022-12-15 20:53    [W:0.058 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site