[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <613d954c-d88c-fa20-f436-75625f11a2ae@solarflare.com>
Date: Wed, 19 Sep 2018 16:38:27 +0100
From: Edward Cree <ecree@...arflare.com>
To: Michal Kubecek <mkubecek@...e.cz>
CC: "John W. Linville" <linville@...driver.com>,
netdev <netdev@...r.kernel.org>,
Ganesh Goudar <ganeshgr@...lsio.com>,
"Jakub Kicinski" <jakub.kicinski@...ronome.com>,
Dustin Byford <dustin@...ulusnetworks.com>,
Dirk van der Merwe <dirk.vandermerwe@...ronome.com>
Subject: Re: [PATCH ethtool] ethtool: support combinations of FEC modes
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 ;)
> 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.
I'll rustle up an RFC patch.
-Ed
Powered by blists - more mailing lists