netdev - Re: [PATCH ethtool,v2] ethtool: add support show/set-time-stamping

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <20200907212542.rnwzu3cn24uewyk4@lion.mk-sys.cz>
Date:   Mon, 7 Sep 2020 23:25:42 +0200
From:   Michal Kubecek <mkubecek@...e.cz>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     "Kevin(Yudong) Yang" <yyd@...gle.com>,
        netdev <netdev@...r.kernel.org>,
        Neal Cardwell <ncardwell@...gle.com>
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 <mkubecek@...e.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