On Thu, 13 Apr 2023 at 10:50, Shung-Hsi Yu <shung-hsi.yu@xxxxxxxx> wrote: > > On Thu, Apr 13, 2023 at 05:23:16PM +0800, Shung-Hsi Yu 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? > > An off-topic, yet somewhat related question that I also tried to figure out > is "why the GitHub mirror for libbpf and bpftool exist at the first place?". > It is a non-trivial amount of work for the maintainers after all. > > For libbpf, the main uses case for GitHub seem to be for it to be used as > submodule for other projects (e.g. pahole[1]), and that alone seem to suffice. Then it should be enough for bpftool, too :) The bcc repository uses it as a submodule, for example. The work is non-trivial, but when compared to libbpf, I managed to preserve most of the Makefile from the kernel tree and all of the C code, and bpftool also gets patches less often. > > For bpftool the reason seems to be less clear[2]. From what I can tell right > now its mainly use for CI (this applies to libbpf as well), which is > definitely useful. Yes. At the moment, the CI present on bpftool's mirror is more limited than libbpf's. But it allows me to test some compilation variants: regular builds, static builds, cross-compiling (to some extent). Some additional checks that would make little sense to have in the kernel repo, too. It's mostly for checking that none of these build configurations break when I sync from the kernel, and helped me find and fix several issues in the build system on the mirror. This CI on the mirror doesn't cover bpftool's features, but these should be tested in the BPF CI itself, so we can catch regressions before patches are merged. There are some tests already, not many, I'd like to improve that someday. Anyway. > > But I wonder whether packaging one of the motives to create the mirrors > initially? Can't seem to find anything in this regard. > > > 1: https://github.com/acmel/dwarves/tree/master/lib > 2: https://lore.kernel.org/bpf/CAEf4BzZ+0XpH_zJ0P78vjzmFAH3kGZ21w3-LcSEG=B=+ZQWJ=w@xxxxxxxxxxxxxx/ It seems like you haven't come across this one?: https://lore.kernel.org/bpf/267a35a6-a045-c025-c2d9-78afbf6fc325@xxxxxxxxxxxxx/t/ Yes, easing packaging was one of the motivations for the mirror. As mentioned in my other answer, I've not taken the time to reach out to package maintainers yet, so this hasn't really materialised at this point. CI, indeed, was another motivation. Submodules, or simply making it easier to hack with bpftool's code, was yet another thing. Microsoft folks intend to make bpftool compatible with eBPF for Windows. It's quite simpler to work on that from a repo which is mostly uncoupled from the Linux tree. Perhaps the most important was to make it easier to just download, build and use bpftool, for all users who need to get the latest version, or to patch it, or to create static builds, or to cross-compile, or whatever reason might cause you to compile it from the sources. For all those cases, getting the mirror is faster and requires less space than getting the kernel repo. This makes a nice difference when periodically rebuilding images in automated workflows, for example. Does this answer your questions? Quentin
