From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752099AbbLRLUI (ORCPT ); Fri, 18 Dec 2015 06:20:08 -0500 Received: from m12-12.163.com ([220.181.12.12]:47256 "EHLO m12-12.163.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751860AbbLRLUG convert rfc822-to-8bit (ORCPT ); Fri, 18 Dec 2015 06:20:06 -0500 Content-Type: text/plain; charset=gb2312 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF From: pi3orama X-Mailer: iPhone Mail (13C75) In-Reply-To: <5673E684.4030000@iogearbox.net> Date: Fri, 18 Dec 2015 19:18:54 +0800 Cc: "Wangnan (F)" , Alexei Starovoitov , 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 Content-Transfer-Encoding: 8BIT Message-Id: 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> <5673E684.4030000@iogearbox.net> To: Daniel Borkmann X-CM-TRANSID: DMCowEDpA0ee63NWBAG+AA--.1975S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7Cr1DuFyfJry5GFyUAFyrWFg_yoW8Kr43pF 4rK395KF1DKwnYyw1kCw1xXrySy393Jay5Jrn8K3y8A398t3Z7Xr43tFW29FW3uanIka4q vr40yryrZ3WDZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07j8Ma8UUUUU= X-Originating-IP: [117.136.38.242] X-CM-SenderInfo: lslt02xdpdqiywtou0bp/1tbiEwLUQFXlcUGaDgAAsR Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 发自我的 iPhone > 在 2015年12月18日，下午6:57，Daniel Borkmann 写道： > >> 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. > Get it, and I remember you told me about this once. There's another goal. When someone introduces new functions to eBPF, like object pin added in these days, switching samples to libbpf will lead he/she to help me improve libbpf, because if a new sample is needed, the libbpf backend must be update correspondingly :) > Cheers, > Daniel