On Thu, 22 Jun 2017 14:37:26 +0300, Gal Pressman wrote: > > Any particular reason for implementing this ABI in ethtool rather than > > via some netlink-based interface? Devlink naturally comes to mind, > > given that cabling problems are not really related to the L2 and netdev > > shouldn't be required for diagnostics.. > > ethtool is already used for reporting and handling of link related stuff > through get/set_link_ksettings. > How is reporting the link modes/port type/speed/etc different from this? > This feature is only an extension of the already existent "link detected" > field. > > Implementing this ABI in devlink is a good idea, but it shouldn't be instead > of ethtool but in addition to ethtool. > Many users already use ethtool for this kind of info, we can tell them to use > devlink to check why their link is down, > but I think it's nicer to have it all in one place.
I understand where you're coming from, but it's a matter of user space tooling. If ethtool has to invoke devlink or know a little of netlink to get this info, so be it. Ethtool implements a lot of features, I'm worried that if we select where things are added based on where the similar features already live, we will be stuck adding ioctls for ever :( But I'm happy to let this go if others don't feel the same way ;) In general thanks for working on this feature, it's very useful!
