On 1/25/22 4:39 AM, Dave Thaler wrote:
Quentin Monnet <quentin@xxxxxxxxxxxxx> writes:
Another thing to consider is that keeping bpftool next to the kernel sources
has been useful to help keeping the tool in sync, for example for adding new
type names to bpftool's lists when the kernel get new program/map types.
We have recently introduced some CI checks that could be adjusted to work
with an external repo and mitigate this issue, but still, it is harder to tell people
to submit changes to a second repository when what they want is just to update
the kernel. I fear this would result in a bit more maintenance on bpftool's side
(but then bpftool's requirements in terms of maintenance are not that big
when compared to bigger tools, and maybe some of it could be automated).
Then the other solution, as you mentioned, would be to take Windows-related
patches for bpftool in the Linux repo. For what it's worth, I don't have any
personal objection to it, but it raises the problems of testing and ownership
(who fixes bugs) for these patches.
Personally I would recommend a third approach. That is, bpftool today
combines both platform-agnostic code and platform-specific code without
clean factoring between them. Instead I would want to see it factored such
that there is a clean API between them, where the platform-agnostic code
can be out-of-tree, and the platform-specific code can be in-tree. This would
allow Windows platform-specific code to similarly be in-tree for the ebpf-for-windows project. Both the Linux kernel and ebpf-for-windows (and any other
future platforms) can then depend on the out-of-tree code along with their
own platform-specific code needed to build and run on their own platform.
That's roughly the approach that I've taken for some other projects where it
has worked well.
I wouldn't mind if tools/bpf/bpftool/ would see some refactoring effort to
make it more platform-agnostic, similar as kernel split out arch/ bits vs
generic code. Needed bits should however still be somewhere under bpftool
dir in the tree, at least for Linux, so that patch series touching kernel +
libbpf + bpftool can be run by the existing CI w/o extra detour to first
patch or requiring feature branch on some external out-of-tree dependency.
Perhaps it would be possible to have platform-specific code pluggable via
lib as one of the build options for bpftool..
Thanks,
Daniel
