[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190318140253.GH30224@lunn.ch>
Date: Mon, 18 Mar 2019 15:02:53 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Petr Machata <petrm@...lanox.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Jiri Pirko <jiri@...lanox.com>,
Ido Schimmel <idosch@...lanox.com>,
"davem@...emloft.net" <davem@...emloft.net>,
Tariq Toukan <tariqt@...lanox.com>,
"jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
"stephen@...workplumber.org" <stephen@...workplumber.org>
Subject: Re: [RFC PATCH net-next 1/3] net: rtnetlink: Add link-down reason to
RTNL messages
On Mon, Mar 18, 2019 at 01:15:41PM +0000, Petr Machata wrote:
>
> Andrew Lunn <andrew@...n.ch> writes:
>
> >> +enum rtnl_link_down_reason_major {
> >> + RTNL_LDR_OTHER,
> >
> > Does 'other' make any sense? Seem better to just not report anything
> > at all, or add a comment that more reasons should be added at the end
> > to reflect whatever the hardware or software can determine.
>
> You still have the minor code to give you some information.
The problem i have with OTHER, is that you know it is not NO_CABLE,
UNSUPPORTED_CABLE, AUTONEG_FAILURE, etc. But for people to know what
OTHER cannot be, they have to know all the codes.
But then later, some other driver writer does the right thing, adds a
new value to the end for a code they can detect. Say for example
SFP_OVERHEATED. This happened to be what the previous driver was
using for OTHER. Now we have one driver returning SFP_OVERHEATED and
the older driver OTHER. So OTHER no longer actually mean 'other', it
just means something random, which could actually be the same as one
of the listed codes.
You can stop this from happening by not having OTHER. Always add a new
code if there is something you can report, but there currently is no
code for it. And the userspace tool should just print the decimal
value if it does not know what text to translate it into.
Andrew
Powered by blists - more mailing lists