Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: > On Fri, Oct 25, 2019 at 4:50 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> Currently, the only way to change the logging output of libbpf is to >> override the print function with libbpf_set_print(). This is somewhat >> cumbersome if one just wants to change the logging level (e.g., to enable > > No, it's not. Yes, it is :) > Having one way of doing things is good, proliferation of APIs is not a > good thing. Either way you require application to write some > additional code. Doing simple vprintf-based (or whatever application > is using to print logs, which libbpf shouldn't care about!) function > with single if is not hard and is not cumbersome. The print function registration is fine for applications that want to control its own logging in detail. This patch is about lowering barriers to entry for people who are starting out with libbpf, and just want to find out why their program isn't doing what it's supposed to. Which is not the point to go figure out an arcane function pointer-based debugging setup API just to get some help. Helping users in this situation is the friendly thing to do, and worth the (quite limited) cost of adding this mechanism. If you're objecting to the new API function, an alternative could be to react to an environment variable? I.e., turn on debugging of LIBBPF_DEBUG=1 is in the environment? That way, users wouldn't even have to add the extra function call, they could just re-run their application with the env var set on the command line... > If you care about helping users to be less confused on how to do that, > I think it would be a good idea to have some sort of libbpf-specific > FAQ with code samples on how to achieve typical and common stuff, like > this one. So please instead consider doing that. The fact that you're suggesting putting in a FAQ entry on *how to enable debug logging* should be proof enough that the current API is confusing... -Toke
