Em Fri, Feb 15, 2019 at 09:21:22PM +0100, Daniel Borkmann escreveu: > On 02/15/2019 07:47 PM, Alexei Starovoitov wrote: > > On 2/15/19 9:25 AM, Arnaldo Carvalho de Melo wrote: > >> Em Fri, Feb 15, 2019 at 05:17:27PM +0000, Alexei Starovoitov escreveu: > >>> On 2/14/19 4:47 AM, Arnaldo Carvalho de Melo wrote: > >>>> I wonder if we should have a libbtf, with the same licensing as libbpf, > >>>> as, for instance, pahole would be interested only in the btf parts, be > >>>> it encoding, loading and pretty printing. > >>> I don't think it's possible to do such split. > >>> .btf.ext section only makes sense together with bpf prog. > >> Well, that part, that is not about types and only makes sense together > >> with the BPF parts could stay in libbpf, no? > > I don't see how. > > .btf.ext is using string section of .btf > > It's all connected. > > Even if it was possible to somehow split them > > I think one big library is better than a bunch of smaller ones. > > It's written in C so .text size concern doesn't apply. > +1, I also think one single library is much better. Keeps dependency > management simple and only after ~3.5 years now mainstream distros > have finally started to ship libbpf as a package. Splitting would just > create more hassle for users and slow down wider adoption. I wasn't thinking about two different tarballs distributed independently, just two libraries as tools like pahole don't use the BPF parts at all, just the type and function descriptions, i.e. BTF. I.e. something like glibc has, where its a single package, but it comes with multiple libraries for well defined things like pthreads, etc. - Arnaldo
