Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)

[David Miller]

From: "John W. Linville" <linville@xxxxxxxxxxxxx>
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.