From mboxrd@z Thu Jan  1 00:00:00 1970
From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Subject: Re: [PATCH v2 09/13] mlx5: add link update device
 operation
Date: Mon, 2 Nov 2015 19:27:40 +0100
Message-ID: <20151102182740.GH3518@6wind.com>
References: <1444067589-29513-1-git-send-email-adrien.mazarguil@6wind.com>
 <1446231162-8075-1-git-send-email-adrien.mazarguil@6wind.com>
 <1446231162-8075-10-git-send-email-adrien.mazarguil@6wind.com>
 <20151102095217.7d40e38f@xeon-e3>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: dev@dpdk.org
To: Stephen Hemminger <stephen@networkplumber.org>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43])
 by dpdk.org (Postfix) with ESMTP id 5AE6C5954
 for <dev@dpdk.org>; Mon,  2 Nov 2015 19:28:00 +0100 (CET)
Received: by wmeg8 with SMTP id g8so66514449wme.0
 for <dev@dpdk.org>; Mon, 02 Nov 2015 10:28:00 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <20151102095217.7d40e38f@xeon-e3>
List-Id: patches and discussions about DPDK <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>

On Mon, Nov 02, 2015 at 09:52:17AM -0800, Stephen Hemminger wrote:
> On Fri, 30 Oct 2015 19:52:38 +0100
> Adrien Mazarguil <adrien.mazarguil@6wind.com> wrote:
> 
> > +static int
> > +mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
> > +{
> > +	struct priv *priv = dev->data->dev_private;
> > +	struct ethtool_cmd edata = {
> > +		.cmd = ETHTOOL_GSET
> > +	};
> > +	struct ifreq ifr;
> > +	struct rte_eth_link dev_link;
> > +	int link_speed = 0;
> > +
> > +	(void)wait_to_complete;
> 
> DPDK style is to use the __rte_unused attribute rather than dummy statements
> to avoid unused warnings.

Thanks for pointing this out, I'm used to avoiding C extensions whenever
possible but will stick to DPDK style next time.

Still, it would be nice if we could steer DPDK away from such extensions as
much as possible. As a library, we should allow user applications to compile
with flags we can't control (such as -pedantic -std=c99, and various
-Wsomething).

-- 
Adrien Mazarguil
6WIND