[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190328115256.2a7cb952@cakuba.netronome.com>
Date: Thu, 28 Mar 2019 11:52:56 -0700
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Michal Kubecek <mkubecek@...e.cz>,
Florian Fainelli <f.fainelli@...il.com>,
David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
Andrew Lunn <andrew@...n.ch>,
John Linville <linville@...driver.com>,
Stephen Hemminger <stephen@...workplumber.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v5 12/22] ethtool: provide string sets with
GET_STRSET request
On Thu, 28 Mar 2019 18:35:24 +0100, Jiri Pirko wrote:
> Thu, Mar 28, 2019 at 03:04:28PM CET, mkubecek@...e.cz wrote:
> >On Thu, Mar 28, 2019 at 02:43:13PM +0100, Jiri Pirko wrote:
> >>
> >> I don't like this. This should not be bitfield/set. This should be
> >> simply nested array of enum values:
> >>
> >> enum ethtool_link_mode {
> >> ETHTOOL_LINK_MODE_10baseT_Half,
> >> ETHTOOL_LINK_MODE_10baseT_Full,
> >> ETHTOOL_LINK_MODE_100baseT_Half,
> >> ETHTOOL_LINK_MODE_100baseT_Full,
> >> ETHTOOL_LINK_MODE_1000baseT_Full,
> >> };
> >
> >We already have such enum. The problem with your "no string" approach is
> >that it requires all userspace applications to (1) keep this enum in
>
> That is how it is usually done. UAPI defines ATTRS and values, userspace
> assigns appropriate strings.
+1 FWIW, I'm with Jiri on the string situation.
Powered by blists - more mailing lists