Re: Bpftool mirror now available

[Daniel Borkmann <daniel@iogearbox.net>]

On 1/25/22 4:39 AM, Dave Thaler wrote:
> Quentin Monnet <quentin@isovalent.com> 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