From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id F35527CD5 for ; Thu, 30 Nov 2017 18:39:33 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6AD7C20D32; Thu, 30 Nov 2017 12:39:33 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 30 Nov 2017 12:39:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=AcN58dIaC39dlpq7vkNYollhQc lYTdqhkD1Dnhksq7I=; b=JweSichEXMNSC8zfYQiEZ2CSCrrGIisH4iWi1KEpct UzhdcCiI1wsk1hm89btSVw2D1XK/v4EL8GBr1tCva1e6c2U27hSN/lx9g6eIZxHn /IK5t3erWLT3srUbw6Q2UI3XevmsVbZnLlmI5AqJjdqzCxcJu8lr94WgEu9n7qv8 I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=AcN58d IaC39dlpq7vkNYollhQclYTdqhkD1Dnhksq7I=; b=ILU5AJMGv2PeCwRRf6gzYH dp/t3/HQZ9BGCaz7A4NCS50+aVA+vQrV3Vp5sEuQMvxtxaI4HcJBz31ARk/DxxEC uy+IsgjCG6gsJQYn8x4f94IOxMcL1+jEnOvFzYK64oSxIyJE+8nZ3Ar4YifxzMNI EUeS/T5F3gCZIiwR84DfCYYfmpgQfFEK2CDOtxYQ9XZ/U0w8TP7NafsKMC9c2zHL leDFF/I3A/AdfKDpQkw/5g82+po2qDCzB++QPnX6wFGYABsiYNEkJcUIyC/yet4L z2kzl0OcK93m5bi7B4uW3XCvUNC3Gn/yw8BS5kwandFF4XDZmH7yPR+RKL30g9PQ == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 13A467FACE; Thu, 30 Nov 2017 12:39:33 -0500 (EST) From: Thomas Monjalon To: Stephen Hemminger Cc: dev@dpdk.org, Ophir Munk , Olga Shern , Pascal Mazon Date: Thu, 30 Nov 2017 18:39:32 +0100 Message-ID: <4022270.ekSSXE0TKz@xps> In-Reply-To: <20171130092042.402243a7@xeon-e3> References: <1512028870-13597-1-git-send-email-ophirmu@mellanox.com> <33612859.oYs3VmdAvV@xps> <20171130092042.402243a7@xeon-e3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC 2/2] net/tap: add eBPF instructions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 17:39:34 -0000 30/11/2017 18:20, Stephen Hemminger: > On Thu, 30 Nov 2017 18:05:22 +0100 > Thomas Monjalon 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.