[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170624190435.GN4875@lunn.ch>
Date: Sat, 24 Jun 2017 21:04:35 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Gal Pressman <galp@...lanox.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
"John W. Linville" <linville@...driver.com>,
Saeed Mahameed <saeedm@...lanox.com>,
Vidya Sagar Ravipati <vidya@...ulusnetworks.com>,
Jiri Pirko <jiri@...lanox.com>,
David Decotigny <decot@...glers.com>, kernel-team@...com
Subject: Re: [RFC PATCH net-next 1/3] ethtool: Add link down reason callback
On Thu, Jun 22, 2017 at 11:09:04AM +0300, Gal Pressman wrote:
>
> >> +enum {
> >> + ETHTOOL_LINK_VENDOR_SPECIFIC = -1, /* Vendor specific issue provided in vendor_reason */
> >> + ETHTOOL_LINK_NO_ISSUE, /* No issue observed with link */
> >> + ETHTOOL_LINK_REASON_UNKNOWN, /* Unknown reason */
> > I think OTHER would be better that UNKNOWN.
>
> Fine with me.
> >> + ETHTOOL_LINK_NETDEV_CARRIER_DOWN, /* Netdev carrier is down */
> >> + ETHTOOL_LINK_ADMIN_DOWN, /* Admin down */
> > These two are interesting. We have that information already. Why do we
> > want it again?
>
> My goal is to gather all link issue reasons in one place.
I'm actually wondering if this is a user space problem. Nearly
everything you list is already available. Some you get from ip link,
others from ethtool or ethtool --module-info, including I2C bus
error, since you would expect EIO or ETIMEOUT.
If you were to write a user space tool using the information what is
currently available, what would be missing?
Andrew
Powered by blists - more mailing lists