Bug#591012: netcfg: Support /sys/class/net/ethX/carrier for link detection?
Petter Reinholdtsen wrote:
> Should netcfg link detection be extended to use
> /sys/class/net/ethX/carrier if it exist? At the moment its
> ethtool_lite() function uses the mii-diag/ethtool kernel API to check link
> status, but the /sys/ file seem to be a more generic way to do this.
In principle, I like this idea -- it's a lot easier to read a file than to
faff around with ioctls. Since the file just reads the result from
netif_carrier_ok(), it should be quite reliable, *as long as* the driver
supports it.
According to the Linux bonding docs (specifically the use_carrier config
parameter), not every driver supports netif_carrier_ok(), and if it doesn't,
then the carrier will always be reported as being 'up'. As such, there's no
way to detect that the info we're getting is bogus, and fall back to another
mechanism. On the other hand, those docs were written years ago, and it's
quite likely that more drivers will have been modified to support
netif_carrier_ok() in the meantime.
However, this does mean that, unless we *can* reasonably assume that all
drivers support this mechanism, we can't use it. Which is a pity, since
it's pretty awesome.
I see a few ways forward:
1) We decide that we can't (ever?) rely on the correctness of
netif_carrier_ok(), and regretfully close this bug report.
2) Come up with some way of determining if netif_carrier_ok() is telling us
lies, and use it when possible with a fallback to ioctls.
3) Decide the risk is manageable (either because someone comes up with info
suggesting that netif_carrier_ok() support is universal, or because the risk
of problems is deemed small enough), and switch ethtool-lite over to use
.../carrier everywhere.
One thing to note: .../carrier will only provide a result if the link has
been brought up by ip link set ethN up. Attempts to read it otherwise will
result in EINVAL. We need to make absolutely sure that the NIC is up before
attempting to query it using this method (and also sanely handle a returned
EINVAL).
Input from other people on the risks of option 3 would be gratefully
appreciated.
- Matt
Reply to: