From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [RFC 2/2] net/tap: add eBPF instructions
Date: Thu, 30 Nov 2017 18:39:32 +0100
Message-ID: <4022270.ekSSXE0TKz@xps>
References: <1512028870-13597-1-git-send-email-ophirmu@mellanox.com>
 <33612859.oYs3VmdAvV@xps> <20171130092042.402243a7@xeon-e3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, Ophir Munk <ophirmu@mellanox.com>,
 Olga Shern <olgas@mellanox.com>, Pascal Mazon <pascal.mazon@6wind.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Return-path: <dev-bounces@dpdk.org>
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
 [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id F35527CD5
 for <dev@dpdk.org>; Thu, 30 Nov 2017 18:39:33 +0100 (CET)
In-Reply-To: <20171130092042.402243a7@xeon-e3>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

30/11/2017 18:20, Stephen Hemminger:
> On Thu, 30 Nov 2017 18:05:22 +0100
> Thomas Monjalon <thomas@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.