From: "John W. Linville" <redacted>
Date: Thu, 14 Dec 2017 16:07:56 -0500
Even without considering the ioctl problesms, the current ethtool
API seems a bit crufty. It has been a catch-all, "where else would it
go?" dumping ground for a long time, and it has accrued a number of
not-entirely-related bits of functionality. In my mind, what needs
to happen is that these various bits of functionality need to be
reorganized into a handful of groupings. Then, each group needs an
API designed around semantics that are natural to the functionality
being addressed. I believe this is essentially the idea that others
have expressed with the "move some of the ethtool bits to devlink"
comments. I think that probably makes sense, although trying to shove
everything into devlink probably makes no more sense than keeping
the entire ethtool API intact on top of a netlink transport. Anyway,
I think that with a reasonable set of groupings, the semantics would
fall-out naturally and implementing them on netlink or any other
suitable transport would be reasonably trivial.
Thanks for your valueable feedback John.
Let's keep in mind that really the core impetus to move ethtool stuff
to netlink is visibility.
Someone trying to monitor network config events in the system can't
see anything that happens with ethtool currently. It's completely
invisible.
Even ancient ifconfig ioctls generate proper netlink events.
Ethtool is one of the few, if not the only, network config mechanism
that elides netlink event visibility.
And I think fixing that core issue is what is driving the focus onto a
pure 1-to-1 conversion, be it to a separate netlink/genetlink family
or to devlink.