From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751894AbbLRK52 (ORCPT ); Fri, 18 Dec 2015 05:57:28 -0500 Received: from www62.your-server.de ([213.133.104.62]:40158 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751710AbbLRK50 (ORCPT ); Fri, 18 Dec 2015 05:57:26 -0500 Message-ID: <5673E684.4030000@iogearbox.net> Date: Fri, 18 Dec 2015 11:57:08 +0100 From: Daniel Borkmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Wangnan (F)" , Alexei Starovoitov CC: ast@kernel.org, agartrell@fb.com, acme@redhat.com, bblanco@plumgrid.com, 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 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> In-Reply-To: <5673AFE0.1000006@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/18/2015 08:04 AM, Wangnan (F) wrote: ... > 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). Having this as a possible user space library seems fine. Only speaking for the tc case specifically here (since you mention it as one example), there's currently no additional value for it. The current loader code there is functional and partially tailored for tc's needs and having this together with the iproute2 repo, it allows us to easily change/ adapt the internal code whenever needed. The only dependency the loader code has is that the BPF syscall got compiled into the kernel and libelf, that's all. libelf is effectively available in distros for more than a decade(s?). And iproute2 is being shipped everywhere already as well (hence also iproute2's minimalism on library dependencies). Switching that code would mean that iproute2 would then depend on libbpf which itself would depend on libelf, until every distro that ships iproute2 will also ship libbpf, it will take a bit. Changes on the code would then need to go through libbpf first, and iproute2 would need to wait until it becomes available to make use of it and probably need to implement some compat code for the time being. Further, as both are decoupled also testing effort increases to make sure nothing breaks among different versions. That said, I prefer that tc's {cls,act}_bpf front-end is shipped to users as it's being done already and that they can use it /now/ as-is. Don't get me wrong, for other tools etc coming up in future, as mentioned, offering it as a public library makes totally sense as not every application developer would want to choose writing his own loader code. Cheers, Daniel