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
| ||
|
Date: Fri, 18 Dec 2015 16:35:25 -0800 From: Alexei Starovoitov <alexei.starovoitov@...il.com> To: "Wangnan (F)" <wangnan0@...wei.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 Fri, Dec 18, 2015 at 03:04:00PM +0800, Wangnan (F) wrote: > > >>However, linux/err.h is not a part of uapi. To make libbpf work, one has to > >>create its > >>own err.h. > >Why tools/include/linux/err.h is not suitable for everyone? > > > >>Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(), in libbpf itself. > >seems odd. we already have user space err.h in tools/include. > > Currently samples/bpf doesn't have an -I$(srctree)/tools/include. > > I tried to add it into CFLAGS of samples/bpf. It causes other problems, let's fix those problem then. > 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. completely agree on the goal of making libbpf to be a standalone library, but disagree on tools/include dependency. If you copy-paste err.h into libbpf either as-is or as LIBBPF_IS_ERR, it's not going to be enough. Soon you'll need another macro from tools/include and so on. imo it's much easier to include tools/include/ as part of standalone libbpf. Also at the time of creation of tools/lib/bpf we agreed that it's LGPL just like tools/lib/traceevent, but I don't see any mention of it in the libbpf source. -- 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