On Fri, Apr 14, 2023 at 02:12:40AM +0100, Quentin Monnet wrote: > 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. Hmm... bcc having bpftool as a submodule is a news to me. bcc having libbpf as a submodule is quite straight forward, but I didn't know bcc depends on bpftool as well. > 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/ That has all I wanted to know and more, not sure how I was able to missed that, my Xapian searching skill really needs more work :) > 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. While for distro packaging the net benefit is somewhat unclear (after all that the point of this thread), I very much agree with the above, this does give users much greater control over the bpftool they can choose to use. > Does this answer your questions? Yes, thanks! > Quentin
