All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Alain Michaud <alainmichaud@google.com>
Cc: Johan Hedberg <johan.hedberg@gmail.com>,
	Alain Michaud <alainm@chromium.org>,
	BlueZ <linux-bluetooth@vger.kernel.org>
Subject: Re: [Bluez PATCH] doc: Add definition for Set Kernel Debug Level
Date: Thu, 23 Jan 2020 06:52:33 +0100	[thread overview]
Message-ID: <DFE9B731-5CB8-4FDA-8E89-1D5A51EAFB67@holtmann.org> (raw)
In-Reply-To: <CALWDO_VC2z8ZxCQM0EBWvkEWJRQKaVy0butAeRc+uUqhpGcyMw@mail.gmail.com>

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=188825.
> 
> 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 traces. That is why we have bt_dev_* etc. error macro and have changed a lot of code to use them. This will hopefully allow us to have errors and warnings directly in the btmon traces. For bluetoothd errors and warnings this already works btw.

I don’t believe that I want to duplicate the dynamic_debug functionality and push even more info into dmesg ring buffer that then needs to be 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 place with the right timestamp.

If we push bt_{info,warn,err} into btmon, it might be simpler to do the same for BT_DBG, but it will of course require extra work since our BT_DBG statements are meant to be compiled out if dynamic_debug is disabled.

Regards

Marcel


  reply	other threads:[~2020-01-23  5:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-20 20:27 [Bluez PATCH] doc: Add definition for Set Kernel Debug Level Alain Michaud
2020-01-21 16:20 ` Marcel Holtmann
2020-01-21 18:25   ` Alain Michaud
2020-01-21 18:33     ` Johan Hedberg
2020-01-21 18:37       ` Alain Michaud
2020-01-22 21:48         ` Alain Michaud
2020-01-23  5:52           ` Marcel Holtmann [this message]
2020-01-23 14:38             ` Alain Michaud
2020-01-23 17:44               ` Marcel Holtmann
2020-01-23 18:04                 ` Alain Michaud
2020-01-23 18:16                   ` Marcel Holtmann
2020-01-23 18:18                     ` Alain Michaud
2020-01-23 23:13                       ` Luiz Augusto von Dentz
2020-01-27 16:54                     ` Marcel Holtmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DFE9B731-5CB8-4FDA-8E89-1D5A51EAFB67@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=alainm@chromium.org \
    --cc=alainmichaud@google.com \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.