Re: [PATCH v1 1/2] thunderbolt: add tracefs support to tb_* logging helpers

[Łukasz Bartosik]

pt., 28 lip 2023 o 17:32 Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> napisał(a):
>
> On Fri, Jul 28, 2023 at 04:50:12PM +0200, Łukasz Bartosik wrote:
> > czw., 27 lip 2023 o 16:47 Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> napisał(a):
> > >
> > > On Thu, Jul 27, 2023 at 03:13:25PM +0200, Łukasz Bartosik wrote:
> > > > Thunderbolt tracing is a lightweight alternative to traditional
> > > > thunderbolt debug logging. While thunderbolt debug logging is quite
> > > > convenient when reproducing a specific issue, it doesn't help when
> > > > something goes wrong unexpectedly. There are a couple of reasons why
> > > > one does not want to enable thunderbolt debug logging at all times:
> > > >
> > > > 1. We don't want to overwhelm kernel log with thunderbolt spam, others
> > > >    want to use it too
> > >
> > > But doesn't the dynamic debug infrastructure allow this today?
> > >
> >
> > Dynamic debug allows only partially what we would like to achieve.
> >
> > Our goal is to be able to gather thunderbolt debug logs from ChromeOS
> > end users when an issue happens. Especially that would be very useful
> > for us in case of issues which reproduction is difficult. We would
> > write thunderbolt debug logs to a separate wrap around buffer provided
> > by trace subsystem. When an issue happens and a user sends a feedback
> > then thunderbolt logs would be attached to the feedback providing
> > more insight into what happened.
>
> The problem is, you don't want 100 different debug log formats and tools
> for the 100 different driver subsystems.
>
> That is why we unified everything on the dev_* format, and the tracing
> tools.  Use them, don't create something new.
>
> > Dynamic debug sends all debug messages to dmesg and with significant
> > number of dynamic dev_dbg prints enabled dmesg may be quickly overwritten
> > and other important logs lost. Also enabling dynamic debug for the
> > entire kernel might
> > not be appropriate for production kernels due to impact on kernel size and perf.
>
> If you look at the typec code, they have their own type of ring-buffer
> for logging things.  Perhaps look at making that more generic like what
> you need here as well, and adding that to the tracing core for everyone
> to use and unify with?
>

Thanks for the comments and pointing me to the typec code for the reference.

Lukasz

> I don't want one-off solutions like this, sorry, that way lies madness,
> madness that we used to have before we unified everything.  Let's learn
> from our past mistakes and not make them again please.
>
> thanks,
>
> greg k-h