Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200120202708.111383-1-alainm@chromium.org> <6E55772A-01D5-4616-B3DB-CC22B935C855@holtmann.org>
 <CALWDO_WyZUvkOgXVSd12q7Trg_=LqSb9KQsXH9_C_k8_kD0ddQ@mail.gmail.com>
 <D0C01568-E48B-46ED-A2CC-D19FB2895756@gmail.com> <CALWDO_Wf3c5Vgt1a_p+pt_SpdkGJnLvneiZZ_1spRVuOr+9n0g@mail.gmail.com>
 <CALWDO_VC2z8ZxCQM0EBWvkEWJRQKaVy0butAeRc+uUqhpGcyMw@mail.gmail.com> <DFE9B731-5CB8-4FDA-8E89-1D5A51EAFB67@holtmann.org>
In-Reply-To: <DFE9B731-5CB8-4FDA-8E89-1D5A51EAFB67@holtmann.org>
From:   Alain Michaud <alainmichaud@google.com>
Date:   Thu, 23 Jan 2020 09:38:29 -0500
Message-ID: <CALWDO_V=Q0725MhnA3hMnvL+hDbGVCa-RCT4d4NCysMo0Fvh7g@mail.gmail.com>
Subject: Re: [Bluez PATCH] doc: Add definition for Set Kernel Debug Level
To:     Marcel Holtmann <marcel@holtmann.org>
Cc:     Johan Hedberg <johan.hedberg@gmail.com>,
        Alain Michaud <alainm@chromium.org>,
        BlueZ <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Marcel,


On Thu, Jan 23, 2020 at 12:52 AM Marcel Holtmann <marcel@holtmann.org> wrot=
e:
>
> Hi Alain,
>
> > Thanks for your patience.  After further research dynamic_debug is not
> > available on retail chromium os user systems for a variety of reasons,
> > some of which you can find in this trail:
> > https://bugs.chromium.org/p/chromium/issues/detail?id=3D188825.
> >
> > Given we need to be able to diagnose things in the field, this is not
> > a good option for this.
> >
> > I hope this helps explain or justify the need for this interface.
>
> the reasoning from Kees is 6 years old. Are his issues still valid?
>
> So I have been looking into pushing bt_{info,warn,err} into the btmon tra=
ces. That is why we have bt_dev_* etc. error macro and have changed a lot o=
f code to use them. This will hopefully allow us to have errors and warning=
s directly in the btmon traces. For bluetoothd errors and warnings this alr=
eady works btw.
>
> I don=E2=80=99t believe that I want to duplicate the dynamic_debug functi=
onality and push even more info into dmesg ring buffer that then needs to b=
e collected and aligned with btmon traces. The big advantage is if you get =
a btmon trace and that has the actual message right in it at the right plac=
e with the right timestamp.
>
> If we push bt_{info,warn,err} into btmon, it might be simpler to do the s=
ame for BT_DBG, but it will of course require extra work since our BT_DBG s=
tatements are meant to be compiled out if dynamic_debug is disabled.

The rational is all still relevant today.  To give you some additional
background, here's how a version of this is currently used:

https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/=
1697851

Note that I don't expect us to upstream this as is, in particular,
it'd expect we'd also want to forward to pr_debug to support
dynamic_debug for systems where it makes sense to use.

>
> Regards
>
> Marcel
>