[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8Bye+fco5o3U1Sj+4WtpC5qy1gqUQUsTS1+BcjZe2ppFPCLg@mail.gmail.com>
Date: Mon, 2 Oct 2023 12:07:41 +0200
From: Łukasz Bartosik <lb@...ihalf.com>
To: jim.cromie@...il.com
Cc: Jason Baron <jbaron@...mai.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
Douglas Anderson <dianders@...omium.org>,
Guenter Roeck <groeck@...gle.com>,
Yaniv Tzoreff <yanivt@...gle.com>,
Benson Leung <bleung@...gle.com>, linux-kernel@...r.kernel.org,
upstream@...ihalf.com,
Vincent Whitchurch <vincent.whitchurch@...s.com>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v1] dynamic_debug: add support for logs destination
pon., 18 wrz 2023 o 09:20 Łukasz Bartosik <lb@...ihalf.com> napisał(a):
>
> pt., 15 wrz 2023 o 20:02 <jim.cromie@...il.com> napisał(a):
> >
> > On Fri, Sep 15, 2023 at 9:49 AM Łukasz Bartosik <lb@...ihalf.com> wrote:
> > >
> > > Add support for selection of dynamic debug logs destination.
> > > When enabled it allows to configure destination of each callsite
> > > individually. The option adds a framework (described by struct
> > > ddebug_dst_ops) which provides flexible means to add a new destination
> > > for debug logs. On top of the framework support for trace instance as
> > > destination is added. By default destination of debug logs is syslog.
> > > Syslog can be set explicitly by using dst keyword or is selected by
> > > default when dst keyword is omitted, for example:
> >
> > A while back,
> > Cc: Vincent Whitchurch <vincent.whitchurch@...s.com>
> > proposed these patches:
> > https://lore.kernel.org/lkml/20200825153338.17061-1-vincent.whitchurch@axis.com/
> >
> > his approach adds a single flag, +x or (my pref) +T
> > which sends the pr_debug to tracefs, independent of +p.
> > Steve Rostedt offered feedback on one of the versions,
> > and one could read that as provisional acceptance.
> >
> > Ive worked his patchset since, it is here:
> > https://github.com/jimc/linux/tree/dd-trc-11
> > (it has some unrelated bits too)
> >
> > but it sits atop another patchset:
> > https://lore.kernel.org/lkml/20230911230838.14461-1-jim.cromie@gmail.com/
> > or for git remote add
> > https://github.com/jimc/linux/tree/dd-fix-5i
> >
>
> I looked through the patches you pointed me to. The solution with
> +T/+x is elegant and tailored to specific needs.
> Our rationale to write pr_debug/dev_dbg logs to tracefs is similar to
> Vincent's to aid us in debugging.
> Unfortunately the solution with +T/+x does not cover our use case.
>
> Our use case is different. We experience issues reported by Chromebook
> users which are difficult to reproduce
> that's why we would like to enable debug logs to be written to tracefs
> on productions systems.
> When users experiences an issues and sends us a feedback report the
> debug logs written to tracefs would be
> attached to the feedback report. We would like to write debug logs to
> a separate trace instances based on
> the subsystem/driver. Our initial areas of interest/issues are usbcore
> and thunderbolt drivers/subsystems.
> More may come in the future.
>
> With my proposal this could be achieved for the thunderbolt subsystem
> with the following steps:
> * enable kernel configuration option CONFIG_DYNAMIC_DEBUG_CORE,
> * enable kernel configuration option DYNAMIC_DEBUG_DST and set its
> operation mode to Static.
> * add the option to the thunderbolt's drivers/thunderbolt/Makefile
> in order to compile in debug logs:
> CFLAGS_nhi.o := -DDYNAMIC_DEBUG_MODULE
> * compile the kernel and update it on a target device,
> * finally append the entry to the kernel boot command line:
> thunderbolt.dyndbg="dst trace:thunderbolt =p"
>
> Both the solutions (I mean +x/+T and mine proposal) have pros and cons.
> Maybe both could coexist together, +x/+T by default and this patch as
> configurable option
> which adds more flexibility ?
>
Jim,
Do you have thoughts/comments about/to my proposal ?
Thanks,
Lukasz
> >
> > syslog and/or tracefs seems sufficient, do you have a 3rd destination ?
> >
>
> I don't have a use case for the third destination, but for example
> adding socket destination to my proposal would be relatively fast and
> easy (that would be for limited use only after a network is up and
> running).
>
> Thanks,
> Lukasz
>
> > thanks
Powered by blists - more mailing lists