lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <87r2b2hn5r.fsf@mellanox.com> Date: Tue, 19 Mar 2019 15:57:53 +0000 From: Petr Machata <petrm@...lanox.com> To: Stephen Hemminger <stephen@...workplumber.org> CC: Andrew Lunn <andrew@...n.ch>, "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> Subject: Re: [RFC PATCH net-next 1/3] net: rtnetlink: Add link-down reason to RTNL messages Stephen Hemminger <stephen@...workplumber.org> writes: > On Tue, 19 Mar 2019 10:18:00 +0000 > Petr Machata <petrm@...lanox.com> wrote: > >> Stephen Hemminger <stephen@...workplumber.org> writes: >> >> > On Mon, 18 Mar 2019 15:02:53 +0100 >> > Andrew Lunn <andrew@...n.ch> wrote: >> > >> >> 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. >> > >> > 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. > > The problem with codes is that without some standard (like IETF) the > values are very system specific and likely to get lots of of version churn. I think this would be even worse with just strings.
Powered by blists - more mailing lists