[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5673B16C.8000002@huawei.com>
Date: Fri, 18 Dec 2015 15:10:36 +0800
From: "Wangnan (F)" <wangnan0@...wei.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
CC: <ast@...nel.org>, <agartrell@...com>, <acme@...hat.com>,
<bblanco@...mgrid.com>, <daniel@...earbox.net>,
<daniel.wagner@...-carit.de>, <davem@...emloft.net>,
<mingo@...nel.org>, <jolsa@...nel.org>, <xiakaixu@...wei.com>,
<holzheu@...ux.vnet.ibm.com>, <yang.shi@...aro.org>,
<linux-kernel@...r.kernel.org>, <pi3orama@....com>
Subject: Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF
On 2015/12/18 15:04, Wangnan (F) wrote:
>
>
> On 2015/12/18 14:19, Alexei Starovoitov wrote:
>> On Fri, Dec 18, 2015 at 09:47:11AM +0800, Wangnan (F) wrote:
>>> This is a limitation in tools/lib/bpf/libbpf.h, which has a #include
>>> <linux/err.h>
>>> in its header.
>>>
>>> libbpf.h requires this include because its API uses ERR_PTR() to encode
>>> error code.
>>> For example, when calling bpf_object__open(), caller should use
>>> IS_ERR() to
>>> check its
>>> return value instead of compare with NULL, and use PTR_ERR() to retrive
>>> error number.
>>>
>>> However, linux/err.h is not a part of uapi. To make libbpf work, one
>>> has to
>>> create its
>>> own err.h.
>>
[SNIP]
>>> What about moving them into include/uapi/linux/filter.h ? Then
>>> normal user programs like those in samples/bpf can access
>>> them easier.
>> we don't want to add these macros to uapi.
>> Why not to add it to
>> tools/include/linux/filter.h
>> instead?
>
> What I want to do in this patchset is not only removing original libbpf.c
> and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
> available library for other userspace tools (tc for example). Switching
> samples/bpf into libbpf is the first step of this goal. From doing this
> I found and fixed some limitation, like those missed BPF map operations.
> Making libbpf.h and bpf.h available for normal userspace programs is also
> important.
>
> Having the above goal, I think you can understand why improving
> tools/include
> is not a good idea. You don't want to force a normal userspace program
> setup
> a similar header environment for using libbpf. It is relatively a small
> library. So it would be good if bpf.h and libbpf.h only depend on what
> can
> be found in uapi.
>
I suddenly realized that only linux/err.h causes problem. Those macros from
filter.h are never accessed by libbpf. So we can drop those filter.h by
making
samples/bpf include from tools/include. However we still need a wrapper in
libbpf to avoid including linux/err.h.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists