Martin Husemann <martin%duskware.de@localhost> writes: > On Tue, Dec 01, 2020 at 09:49:39AM -0500, Greg Troxel wrote: >> I don't see why part of npf is built in and the other part isn't. > > Indeed, for architectures supported by bpfjit (and where it works) they > should go together. I have a test build in progress with BPFJIT/SLJIT. The plot thickens: bpfjit(4) says it supports armv5 armv7, and thumb2. That's only part of the evbarm port, and we don't as far as I know have a notion of options per cpu variant. net.bpf.jit appears to be 0 afer loading the module, which I think means that there will no compilation. bpfjit(4) implies that enabling the option results in comilation. BPFJIT/SLJIT is missing from ALL. Obviously that's a bug and after a test build I'll commit it. (objections?) So: If the module being loaded (or compiled in) doesn't result in JIT, then the warning about not loading it really makes no sense. If we want to leave it that way, I would say we should leave this out of defaults and not warn. This pivots bpfjit to an optional improvement, not a bug when missing. If we don't like that it should be enabled by default. Or perhaps npf uses bpfjit even when it is not enabled, and we need doc fixes? It seems strange to require SLJIT in the kernel config as usually depending things just happen.
Attachment:
signature.asc
Description: PGP signature