From: Petr Machata <petrm@mellanox.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Jiri Pirko <jiri@mellanox.com>,
Ido Schimmel <idosch@mellanox.com>,
"davem@davemloft.net" <davem@davemloft.net>,
Tariq Toukan <tariqt@mellanox.com>,
"jakub.kicinski@netronome.com" <jakub.kicinski@netronome.com>
Subject: Re: [RFC PATCH net-next 1/3] net: rtnetlink: Add link-down reason to RTNL messages
Date: Tue, 19 Mar 2019 10:18:00 +0000 [thread overview]
Message-ID: <87tvfzgobt.fsf@mellanox.com> (raw)
In-Reply-To: <20190318085221.037ad66a@shemminger-XPS-13-9360>
Stephen Hemminger <stephen@networkplumber.org> writes:
> On Mon, 18 Mar 2019 15:02:53 +0100
> Andrew Lunn <andrew@lunn.ch> wrote:
>
>> On Mon, Mar 18, 2019 at 01:15:41PM +0000, Petr Machata wrote:
>> >
>> > Andrew Lunn <andrew@lunn.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.
>
> Gut feel is that enumerated values are going to grow and grow and be
> long term API headache.
>
> Would it be possible to use a string like the external ack error
> message?
It would, but then if any automated tools want to make use of it beyond
just blindly displaying it, they will need to parse it with all the
usual problems. In the end the string itself becomes the API anyway.
Adding a string would make sense as an extra piece of information, not
as the primary channel. Extack is like this as well, the primary channel
there is errno.
next prev parent reply other threads:[~2019-03-19 10:18 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-15 17:56 [RFC PATCH net-next 0/3] RTNL: Add link-down reason reporting Petr Machata
2019-03-15 17:56 ` [RFC PATCH net-next 1/3] net: rtnetlink: Add link-down reason to RTNL messages Petr Machata
2019-03-16 2:26 ` Jakub Kicinski
2019-03-17 0:24 ` Michal Kubecek
2019-03-18 12:34 ` Petr Machata
2019-03-18 12:43 ` Michal Kubecek
2019-03-18 13:12 ` Andrew Lunn
2019-03-16 2:26 ` Andrew Lunn
2019-03-18 13:15 ` Petr Machata
2019-03-18 13:33 ` Andrew Lunn
2019-03-18 13:47 ` Petr Machata
2019-03-18 14:02 ` Andrew Lunn
2019-03-18 15:52 ` Stephen Hemminger
2019-03-19 10:18 ` Petr Machata [this message]
2019-03-19 11:56 ` Michal Kubecek
2019-03-19 15:42 ` Stephen Hemminger
2019-03-19 15:57 ` Petr Machata
2019-03-17 22:38 ` Roopa Prabhu
2019-03-18 0:03 ` Andrew Lunn
2019-03-28 17:59 ` Petr Machata
2019-03-28 19:51 ` Andrew Lunn
2019-04-23 13:41 ` Jiri Pirko
2019-03-18 12:15 ` Petr Machata
2019-03-15 17:56 ` [RFC PATCH net-next 2/3] mlxsw: reg: Add Port Diagnostics Database Register Petr Machata
2019-03-15 17:56 ` [RFC PATCH net-next 3/3] mlxsw: spectrum: Add rtnl_link_ops Petr Machata
2019-03-16 2:06 ` [RFC PATCH net-next 0/3] RTNL: Add link-down reason reporting Andrew Lunn
2019-03-18 12:11 ` Petr Machata
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tvfzgobt.fsf@mellanox.com \
--to=petrm@mellanox.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=idosch@mellanox.com \
--cc=jakub.kicinski@netronome.com \
--cc=jiri@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=tariqt@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.