On 2020/10/16 3:57, Alexei Starovoitov wrote: > On Thu, Oct 15, 2020 at 12:26 PM Jakub Kicinski <k...@kernel.org> wrote: >> >> On Thu, 15 Oct 2020 12:03:14 -0700 Alexei Starovoitov wrote: >>> On Thu, Oct 15, 2020 at 11:56 AM Jakub Kicinski <k...@kernel.org> wrote: >>>> How so? It's using in-tree headers instead of system ones. >>>> Many samples seem to be doing the same thing. >>> >>> There is no such thing as "usr/include" in the kernel build and source >>> trees. >> >> Hm. I thought bpfilter somehow depends on make headers. But it doesn't >> seem to. Reverting now. > > Thanks! > Right. To explain it a bit further for the author of the patch: > Some samples makefiles use this -I usr/include pattern. > That's different. This local "usr/include" is a result of 'make > headers_install'. I didn't notice this, sorry for the wrong fix. > For samples and such it's ok to depend on that, but bpfilter is > the part of the kernel build. > It cannot depend on the 'make headers_install' step, > so the fix has to be different. Yes, this should rework. > >>>>> Also please don't take bpf patches. >>>> >>>> You had it marked it as netdev in your patchwork :/ >>> >>> It was delegated automatically by the patchwork system. >>> I didn't have time to reassign, but you should have known better >>> when you saw 'bpfilter' in the subject. >> >> The previous committers for bpfilter are almost all Dave, so I checked >> your patchwork to make sure and it was netdev... > > It was my fault. I was sloppy in the past and didn't pay enough attention > to bpfilter and it started to bitrot because Dave was applying patches > with his normal SLAs while I was silent. > . >
