Date: Fri, 18 Dec 2015 16:35:25 -0800
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: "Wangnan (F)" <wangnan0@huawei.com>
Cc: ast@kernel.org, agartrell@fb.com, acme@redhat.com, bblanco@plumgrid.com,
        daniel@iogearbox.net, daniel.wagner@bmw-carit.de, davem@davemloft.net,
        mingo@kernel.org, jolsa@kernel.org, xiakaixu@huawei.com,
        holzheu@linux.vnet.ibm.com, yang.shi@linaro.org,
        linux-kernel@vger.kernel.org, pi3orama@163.com
Subject: Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF
Message-ID: <20151219003523.GA68236@ast-mbp.thefacebook.com>
References: <1450329794-161948-1-git-send-email-wangnan0@huawei.com>
 <1450329794-161948-9-git-send-email-wangnan0@huawei.com>
 <20151217231138.GA34078@ast-mbp.thefacebook.com>
 <5673659F.9090004@huawei.com>
 <20151218061929.GA59584@ast-mbp.thefacebook.com>
 <5673AFE0.1000006@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5673AFE0.1000006@huawei.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2118
Lines: 47

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/