On Mon, Sep 07, 2020 at 06:56:20PM +0200, Eric Dumazet wrote: > On Mon, Sep 7, 2020 at 2:53 PM Michal Kubecek <mkube...@suse.cz> wrote: > > > > As I said in response to v1 patch, I don't like the idea of adding a new > > ioctl interface to ethool when we are working on replacing and > > deprecating the existing ones. Is there a strong reason why this feature > > shouldn't be implemented using netlink? > > I do not think this is a fair request. > > All known kernels support the ioctl(), none of them support netlink so far.
Several years ago, exactly the same was true for bonding, bridge or vlan configuration: all known kernels supported ioctl() or sysfs interfaces for them, none supported netlink at that point. By your logic, the right course of action would have been using ioctl() and sysfs for iproute2 support. Instead, rtnetlink interfaces were implemented and used by iproute2. I believe it was the right choice. > Are you working on the netlink interface, or are you requesting us to > implement it ? If it helps, I'm willing to write the kernel side. Or both, if necessary, just to avoid adding another ioctl monument that would have to be kept and maintained for many years, maybe forever. > The ioctl has been added years ago, and Kevin patch is reasonable enough. And there is a utility using the ioctl, as Andrew pointed out. Just like there were brctl and vconfig and ioctl they were using. The existence of those ioctl was not considered sufficient reason to use them when bridge and vlan support was added to iproute2. I don't believe today's situation with ethtool is different. Michal
