From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michal Kubecek <mkubecek@suse.cz>
Subject: Re: [PATCH ethtool] ethtool: support combinations of FEC modes
Date: Wed, 19 Sep 2018 17:56:09 +0200
Message-ID: <20180919155609.GH3876@unicorn.suse.cz>
References: <518b8b8b-0151-1053-3798-6009044ed53a@solarflare.com>
 <20180919144117.GF3876@unicorn.suse.cz>
 <613d954c-d88c-fa20-f436-75625f11a2ae@solarflare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: "John W. Linville" <linville@tuxdriver.com>,
        netdev <netdev@vger.kernel.org>,
        Ganesh Goudar <ganeshgr@chelsio.com>,
        Jakub Kicinski <jakub.kicinski@netronome.com>,
        Dustin Byford <dustin@cumulusnetworks.com>,
        Dirk van der Merwe <dirk.vandermerwe@netronome.com>
To: Edward Cree <ecree@solarflare.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mx2.suse.de ([195.135.220.15]:49754 "EHLO mx1.suse.de"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S1728254AbeISVen (ORCPT <rfc822;netdev@vger.kernel.org>);
        Wed, 19 Sep 2018 17:34:43 -0400
Content-Disposition: inline
In-Reply-To: <613d954c-d88c-fa20-f436-75625f11a2ae@solarflare.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Wed, Sep 19, 2018 at 04:38:27PM +0100, Edward Cree wrote:
> On 19/09/18 15:41, Michal Kubecek wrote:
> > I'm sorry I didn't notice this before the patch was accepted but as it's
> > not in a release yet, maybe it's still not too late.
> >
> > Could I suggest to make the syntax consistent with other options?
> I didn't realise ethtool had any patterns to be consistent with ;)

Way too many, I must say. :-) That is why I wasn't happy about adding
another.

> > I mean rather than a comma separated list to use either
> >
> >   ethtool --set-fec <dev> encoding enc1 enc2 ...
> but yes this looks fine to me, as long as we're reasonably confident that
>  we won't want to add new parameters (that might require determining
>  whether enc2 is an encoding or a parameter name) in the future, because
>  while the parsing wouldn't be impossible it might get ugly.

This problem already exists for "-s ... msglvl". In the parser for the
netlink series I introduced an "end of list" marker (tentatively "--")
for this purpose, perhaps that could be a way.

> I'll rustle up an RFC patch.

Thank you.

Michal Kubecek