On Thu, Dec 15, 2022 at 2:11 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Thu, 15 Dec 2022 18:45:37 +0000 > Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> 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
