lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 7 Sep 2020 23:25:42 +0200
From:   Michal Kubecek <>
To:     Eric Dumazet <>
Cc:     "Kevin(Yudong) Yang" <>,
        netdev <>,
        Neal Cardwell <>
Subject: Re: [PATCH ethtool,v2] ethtool: add support show/set-time-stamping

On Mon, Sep 07, 2020 at 06:56:20PM +0200, Eric Dumazet wrote:
> On Mon, Sep 7, 2020 at 2:53 PM Michal Kubecek <> 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.


Powered by blists - more mailing lists