linux-kernel - Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF

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] [day] [month] [year] [list]

Message-ID: <20151219003523.GA68236@ast-mbp.thefacebook.com>
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/