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
