Hi Marcel, On Thu, Jan 23, 2020 at 12:52 AM Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > > 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. 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 >
