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

Message-Id: <D3913CEC-C91C-4850-BF31-406AA36D3A57@163.com>
Date:	Fri, 18 Dec 2015 19:18:54 +0800
From:	pi3orama <pi3orama@....com>
To:	Daniel Borkmann <daniel@...earbox.net>
Cc:	"Wangnan (F)" <wangnan0@...wei.com>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	ast@...nel.org, agartrell@...com, acme@...hat.com,
	bblanco@...mgrid.com, 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
Subject: Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF



发自我的 iPhone

> 在 2015年12月18日，下午6:57，Daniel Borkmann <daniel@...earbox.net> 写道：
> 
>> 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

--
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/