RE: Bpftool mirror now available

[Dave Thaler <dthaler@microsoft.com>]

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.

Dave