lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ