Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230727131326.2282301-1-lb@semihalf.com> <2023072705-palpitate-cut-874b@gregkh>
 <CAK8ByeJYtFcMbEabSDJwXhE3jYY2xQG+JHR0gpwh6_=yg+AXjw@mail.gmail.com> <2023072825-alfalfa-skincare-23b2@gregkh>
In-Reply-To: <2023072825-alfalfa-skincare-23b2@gregkh>
From:   =?UTF-8?Q?=C5=81ukasz_Bartosik?= <lb@semihalf.com>
Date:   Fri, 28 Jul 2023 17:49:49 +0200
Message-ID: <CAK8ByeK-pue7o2r5kKgxR=si9BT3E_SSEXkmka84JVW0_L3aFg@mail.gmail.com>
Subject: Re: [PATCH v1 1/2] thunderbolt: add tracefs support to tb_* logging helpers
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     Andreas Noever <andreas.noever@gmail.com>,
        Michael Jamet <michael.jamet@intel.com>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        Yehezkel Bernat <YehezkelShB@gmail.com>,
        linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
        upstream@semihalf.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

pt., 28 lip 2023 o 17:32 Greg KH <gregkh@linuxfoundation.org> napisa=C5=82(=
a):
>
> On Fri, Jul 28, 2023 at 04:50:12PM +0200, =C5=81ukasz Bartosik wrote:
> > czw., 27 lip 2023 o 16:47 Greg KH <gregkh@linuxfoundation.org> napisa=
=C5=82(a):
> > >
> > > On Thu, Jul 27, 2023 at 03:13:25PM +0200, =C5=81ukasz 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 wh=
y
> > > > one does not want to enable thunderbolt debug logging at all times:
> > > >
> > > > 1. We don't want to overwhelm kernel log with thunderbolt spam, oth=
ers
> > > >    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 overwritt=
en
> > 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