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. Dave
