From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 90E87C43381 for ; Tue, 19 Mar 2019 15:42:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4C9EA2083D for ; Tue, 19 Mar 2019 15:42:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=networkplumber-org.20150623.gappssmtp.com header.i=@networkplumber-org.20150623.gappssmtp.com header.b="n9SAbqq0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727054AbfCSPmM (ORCPT ); Tue, 19 Mar 2019 11:42:12 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:36193 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726466AbfCSPmM (ORCPT ); Tue, 19 Mar 2019 11:42:12 -0400 Received: by mail-pf1-f193.google.com with SMTP id p10so7162761pff.3 for ; Tue, 19 Mar 2019 08:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=9mWFs/dtzi+lQO2CyMYLddp7MtjebBGmk8kQc01Qnok=; b=n9SAbqq0ICydKqj0PfHpCHpUvcxZKrBW/NM98pR4m81+I5Z18o+vKvSDgti+ii4eha onlYPuI65whtXUeYuGzi7ofyz0Md4axfXrk/UIWTEVBIfgJ9iokqSxEEq9kexPKpMkST oIYKSfv5vrSpxLhqQD8s9N5WUKP2JC/wEkixXXLkHsMRq+SuxTEgpaWNhqtNt2eawNwW KhB6FUohH/UOjiBcf2KYgaPCQOt3vf0jJf4Qm548qVVukOd0v2EZwL2iVa9NWdWFt+U+ mnRgkM6BF80eh/zVlMEeGmqXmOZkXyUao0BNJTA7F9fMpDzRofjh6wfM4HOYwpVTDPZo mQJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=9mWFs/dtzi+lQO2CyMYLddp7MtjebBGmk8kQc01Qnok=; b=ici0FmwhUJP2jEQX82j0EUKXtVR/Wp/iSjUeMH8yM3Ow+Q/sL2hFnxqTTAq/ZcC735 oeKoEcg4rDwz+ZkPjJCa1vtMzEJWWhF4pN5X9fNrwUB9r2ZFWuK3K+kYnNBiUh/JFrvd vHprxkgGstI+Jkja+mDg0hEPyiQ+/SMKXEA6nZHlwkBchMj7/6qG4YgS0bDWrDWA6KsZ eWlaiTibov1n283sttpK5gSy0VyoOX/5dU9/qsjYhZRWaEcfr+XTbP//+eNwTQTbDPgk 0xgJU+WfDfe+l5LJ/527cDyk/zrReO5gc/Vtle87clax/7a90LrpSv/+iVuzS8Go4wfI RIdQ== X-Gm-Message-State: APjAAAV67tqOJNra7irNOGWexJEwVNPlz4bv3Jfm3gcZPcNMjn5idUjo 2uQDUnMqe20l7VW8FhVAtTUvzQ== X-Google-Smtp-Source: APXvYqyHt4Oxw0bpWAbL3/CqatnCvUtTCU5St1mljMszyhev49Y5pET8iGHgO8epnetGzVTH7DoG0w== X-Received: by 2002:a17:902:87:: with SMTP id a7mr2904277pla.295.1553010131101; Tue, 19 Mar 2019 08:42:11 -0700 (PDT) Received: from shemminger-XPS-13-9360 (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id l7sm47634195pfj.162.2019.03.19.08.42.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Mar 2019 08:42:10 -0700 (PDT) Date: Tue, 19 Mar 2019 08:42:06 -0700 From: Stephen Hemminger To: Petr Machata Cc: Andrew Lunn , "netdev@vger.kernel.org" , Jiri Pirko , Ido Schimmel , "davem@davemloft.net" , Tariq Toukan , "jakub.kicinski@netronome.com" Subject: Re: [RFC PATCH net-next 1/3] net: rtnetlink: Add link-down reason to RTNL messages Message-ID: <20190319084206.6553a9f1@shemminger-XPS-13-9360> In-Reply-To: <87tvfzgobt.fsf@mellanox.com> References: <3a247e91ebe81cdae4bae27ec1631c5015fb943f.1552672441.git.petrm@mellanox.com> <20190316022658.GC29548@lunn.ch> <87zhpsgw7j.fsf@mellanox.com> <20190318140253.GH30224@lunn.ch> <20190318085221.037ad66a@shemminger-XPS-13-9360> <87tvfzgobt.fsf@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 19 Mar 2019 10:18:00 +0000 Petr Machata wrote: > Stephen Hemminger writes: > > > On Mon, 18 Mar 2019 15:02:53 +0100 > > Andrew Lunn wrote: > > > >> On Mon, Mar 18, 2019 at 01:15:41PM +0000, Petr Machata wrote: > >> > > >> > Andrew Lunn 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. 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.