On Mon, Apr 17, 2023 at 05:20:03PM -0700, Andrii Nakryiko wrote: > On Fri, Apr 14, 2023 at 9:15 AM Michal Suchánek <msuchanek@xxxxxxx> wrote: > > > > On Fri, Apr 14, 2023 at 01:30:02PM +0100, Quentin Monnet wrote: > > > 2023-04-14 11:50 UTC+0200 ~ Michal Suchánek <msuchanek@xxxxxxx> > > > > Hello, > > > > > > > > On Fri, Apr 14, 2023 at 01:35:20AM +0100, Quentin Monnet wrote: > > > >> Hi Shung-Hsi, > > > >> > > > >> On Thu, 13 Apr 2023 at 10:23, Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx> wrote: > > > >>> > > > >>> Hi, > > > >>> > > > >>> I'm considering switch to bpftool's mirror on GitHub for packaging (instead > > > >>> of using the source found in kernel), but realize that it should goes > > > >>> hand-in-hand with how libbpf is packaged, which eventually leads these > > > >>> questions: > > > >>> > > > >>> What is the suggested approach for packaging bpftool and libbpf? > > > >>> Which source is preferred, GitHub or kernel? > > > >> > > > >> As you can see from the previous discussions, the suggested approach > > > >> would be to package from the GitHub mirror, with libbpf and bpftool in > > > >> sync. > > > >> > > > >> My main argument for the mirror is that it keeps things simpler, and > > > >> there's no need to deal with the rest of the kernel sources for these > > > >> packages. Download from the mirrors, build, ship. But then I have > > > >> limited experience at packaging for distros, and I can understand > > > >> Toke's point of view, too. So ultimately, the call is yours. > > > > > > > > Things get only ever more complex when submodules are involved. > > > > > > I understand the generic pain points from your other email. But could > > > you be more specific for the case of bpftool? It's not like we're > > > shipping all lib dependencies as submodules. Sync-ups are specifically > > > aligned to the same commit used to sync the libbpf mirror, so that it's > > > pretty much as if we had the right version of the library shipped in the > > > repository - only, it's one --recurse-submodules away. > > > > It's so in every project that uses submodules. Except git does not > > recurse into submodules by default, you have to fix it up by hand. > > Forges don't support submodules so you will not get the submodule when > > downloading the project archive, and won't see it the the project tree. > > git submodule update --init --recursive didn't work? That's one part of the manual fixup. The other part is after each git operation that could possibly cause the submodules to go out of sync, basically any operation that changes the checked-out commit. Of course, you can make some shell aliases that append whatever submodule chicanery to whatever git command you might issue, and tell everyone else to do that, and then it will work in that one shell, and not in any other shell nor any tool that invokes git directly. > > After previous experience with submodules I did not even try, I just > > patched the makefile to use system libbpf before attempting anything > > else. > > Quentin mentioned that he's packaging (or will package) libbpf sources > as part of bpftool release on Github. I've been this for other > libbpf-using tools as well, and it works pretty well (at least for > Fedora and ArchLinux). E.g., srcs-full-* archives for veristat ([0]) > > By switching up actual libbpf used to compile with bpftool, you are > potentially introducing subtle problems that your users will be quite > unhappy about, if they run into them. Let's work together to make it > easier for you to package bpftool properly. We can't switch bpftool to > reliably use system-wide libbpf (either static or shared, doesn't > matter) because of dependency on internal functionality. > > > [0] https://github.com/libbpf/veristat/releases/tag/v0.1 So how many copies of libbpf do I need for having a CO-RE toolchain? Will different tools have different view of the kernel because they each use different private copy of libbpf with different features? When there is a bug in libbpf how many places need to be patched to fix it? Thanks Michal
