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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110101035358.gq5...@hezmatt.org
