From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@fb.com>, bpf <bpf@vger.kernel.org>,
Networking <netdev@vger.kernel.org>
Subject: Re: [PATCH bpf-next] libbpf: Add libbpf_set_log_level() function to adjust logging
Date: Sun, 27 Oct 2019 12:08:36 +0100 [thread overview]
Message-ID: <87sgnejvij.fsf@toke.dk> (raw)
In-Reply-To: <CAEf4BzZAutRXf+W+ExaHjFMtWCfot9HkTWZNGuPckBiXqFcJeQ@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> On Fri, Oct 25, 2019 at 4:50 AM Toke Høiland-Jørgensen <toke@redhat.com> 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
next prev parent reply other threads:[~2019-10-27 11:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-24 13:21 [PATCH bpf-next] libbpf: Add libbpf_set_log_level() function to adjust logging Toke Høiland-Jørgensen
2019-10-25 16:58 ` Andrii Nakryiko
2019-10-27 11:08 ` Toke Høiland-Jørgensen [this message]
2019-10-27 20:00 ` Andrii Nakryiko
2019-10-27 20:55 ` Toke Høiland-Jørgensen
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=87sgnejvij.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox