30/11/2017 18:20, Stephen Hemminger: > On Thu, 30 Nov 2017 18:05:22 +0100 > Thomas Monjalon <tho...@monjalon.net> wrote: > > > 30/11/2017 17:54, Stephen Hemminger: > > > Loading BPF is a could solution to doing dynamic flow matching. > > > It needs to be done differently to be accepted. > > > > > > Putting raw machine instructions in source code is as bad as binary > > > blobs. You need to provide original source of program and then have > > > build instructions to create any needed code. > > > > The source program is provided in this patch: tap_bpf_program.c > > It is pre-compiled to avoid requiring too many dependencies when building > > DPDK. > > But the "freedom to modify" comes into play here. If a *evil* vendor builds > an application based on DPDK and does not provide source. Then user still > deserves > the right to modify the eBPF program that it loads as GPL. The best solution > is to make the TAP PMD loader routine load the program from a file. > Although I am certainly not a FSF legal scholar, putting GPL'd object code in > TAP PMD risks accusations of being a derived or combined work.
Good point. The compiled BPF may be provided as a plugin file. So we would be free to not package this GPL file.
