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:55 UTC|newest]
Thread overview: 21+ 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 ` 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.com \
--cc=ast@fb.com \
--cc=eric@regit.org \
--cc=joe@ovn.org \
--cc=linux-kernel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.