From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id C193630D for ; Wed, 2 Jul 2014 15:07:08 +0200 (CEST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s62D7PWM010740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 Jul 2014 09:07:26 -0400 Received: from localhost (vpn1-7-51.gru2.redhat.com [10.97.7.51]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s62D7OFE000821; Wed, 2 Jul 2014 09:07:25 -0400 Date: Wed, 2 Jul 2014 10:07:23 -0300 From: Flavio Leitner To: Thomas Monjalon Message-ID: <20140702130723.GU5631@t520.home> References: <1404238780-19596-1-git-send-email-fbl@redhat.com> <5006516.KlozUPNl4J@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5006516.KlozUPNl4J@xps13> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] net: get rid of SET_ETHTOOL_OPS X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 13:07:09 -0000 On Wed, Jul 02, 2014 at 11:48:51AM +0200, Thomas Monjalon wrote: > Hi Flavio, > > 2014-07-01 15:19, Flavio Leitner: > > The SET_ETHTOOL_OPS has been removed from upstream, so it > > breaks the dpdk build with recent kernels. > > > > Signed-off-by: Flavio Leitner > > You are removing SET_ETHTOOL_OPS calls. Yes. > In a previous patch, Aaro Koskinen made the choice to redefine the macro > in kcompat files. I missed that one. > I don't know what will be the choice of Intel in the sourceforge base driver. > So I've applied Aaro's patch as there are less modifications of the base > driver: > http://dpdk.org/browse/dpdk/commit/?id=e0b7ca0c0383411 Since the macro is a simple pointer assignment, I didn't see any reason for keeping it around. But maybe I am missing something. fbl