From: "Wangnan (F)" <wangnan0@huawei•com>
To: Joe Stringer <joe@ovn•org>, Eric Leblond <eric@regit•org>
Cc: netdev <netdev@vger•kernel.org>, <linux-kernel@vger•kernel.org>,
<ast@fb•com>
Subject: Re: [PATCH 1/8] tools lib bpf: add error functions
Date: Wed, 19 Oct 2016 09:53:12 +0800 [thread overview]
Message-ID: <5806D208.90308@huawei.com> (raw)
In-Reply-To: <CAPWQB7Fvz=MkHGRVPR924BXzuWuLn6VTqaNGR+x_TYhycdOLag@mail.gmail.com>
On 2016/10/19 6:52, Joe Stringer wrote:
> On 16 October 2016 at 14:18, Eric Leblond <eric@regit•org> wrote:
>> The include of err.h is not explicitely needed in exported
>> functions and it was causing include conflict with some existing
>> code due to redefining some macros.
>>
>> To fix this, let's have error handling functions provided by the
>> library. Furthermore this will allow user to have an homogeneous
>> API.
>>
>> Signed-off-by: Eric Leblond <eric@regit•org>
> Does it need to return the error like this or should we just fix up
> the bpf_object__open() API to return errors in a simpler form?
>
> There's already libbpf_set_print(...) for outputting errors, is it
> reasonable to just change the library to return NULLs in error cases
> instead?
Returning error code to caller so caller knows what happen.
Other subsystems in perf also do this.
Perf hides libbpf's error output (make it silent unless -v),
so it needs a way for receiving libbpf's error code.
I think this patch is good, decouple libbpf.h and kernel headers.
Thank you.
next prev parent reply other threads:[~2016-10-19 1:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-16 21:18 [PATCH 0/8] tools lib bpf: fixes and functional upgrade Eric Leblond
2016-10-16 21:18 ` [PATCH 1/8] tools lib bpf: add error functions Eric Leblond
2016-10-17 1:47 ` Wangnan (F)
2016-10-18 22:52 ` Joe Stringer
2016-10-19 1:53 ` Wangnan (F) [this message]
2016-10-16 21:18 ` [PATCH 2/8] uapi linux bpf: add max value to enum Eric Leblond
2016-10-16 21:18 ` [PATCH 3/8] tools: Sync tools/include/uapi/linux/bpf.h with the kernel Eric Leblond
2016-10-17 1:48 ` Wangnan (F)
2016-10-16 21:18 ` [PATCH 4/8] tools lib bpf: export function to set type Eric Leblond
2016-10-17 1:56 ` Wangnan (F)
2016-10-16 21:18 ` [PATCH 5/8] tools lib bpf: add missing functions Eric Leblond
2016-10-17 2:16 ` Wangnan (F)
2016-10-16 21:18 ` [PATCH 6/8] tools lib bpf: improve warning Eric Leblond
2016-10-17 2:17 ` Wangnan (F)
2016-10-16 21:18 ` [PATCH 7/8] tools lib bpf: fix maps resolution Eric Leblond
2016-10-17 2:23 ` Wangnan (F)
2016-11-07 18:23 ` Wangnan (F)
2016-11-07 18:40 ` Eric Leblond
2016-11-08 22:08 ` Wangnan (F)
2016-10-16 21:18 ` [PATCH 8/8] tools lib bpf: install header file Eric Leblond
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=5806D208.90308@huawei.com \
--to=wangnan0@huawei$(echo .)com \
--cc=ast@fb$(echo .)com \
--cc=eric@regit$(echo .)org \
--cc=joe@ovn$(echo .)org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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