On Tue, Mar 30, 2021 at 1:28 PM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > In the other thread you've proposed to copy paste hash implemenation > > into pahole. That's not ideal. If we had libbpfutil other projects > > could have used that without copy-paste. > > I know it's not ideal. But I don't think libbpf should be in the > business of providing generic data structures with stable APIs either. There is a need for hash in pahole and it's already using libbpf. Would be good to reuse the code. > > that's today. Plus mandatory libelf and libz. > > I would like to have libsysbpf that doesn't depend on libelf/libz > > for folks that don't need it. > > TBH, bpf.c is such a minimal shim on top of bpf() syscall, that > providing all of its implementation as a single .h wouldn't be too > horrible. Then whatever applications want those syscall wrappers would > just include bpf/bpf.h and have no need for the library at all. 1k line bpf.h. hmm. That's not going to be a conventional C header, but it could work I guess. > > Also I'd like to see symbolizer to be included in "libbpf package". > > Currently it's the main component that libbcc offers, but libbpf doesn't. > > Say we don't split libbpf. Then symbolizer will bring some dwarf library > > (say libdwarves ~ 1Mbyte) and libiberty ~ 500k (for c++ demangle). > > Now we're looking at multi megabyte libbpf package. > > Right, which is one of the reasons why it probably doesn't belong in > libbpf at all. Another is that it's not BPF-specific functionality at > all. symbolizer, usdt, python and lua bindings is what made libbcc successful. I think "libbpf package" should include everything that bpf tracing folks might need. Getting -l flags correct from a single package isn't a big deal compared with the need to deal with different packages that depend on each other. > I'm against pro-active splitting just in case. I'd rather discuss > specific problems when we get to them. I think it's premature right > now to split libbpf. Fine. I'm mainly advocating to change the mental model to see libbpf as a collection of tools and libraries and not just single libbpf.a
