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] [day] [month] [year] [list]
Date:   Tue, 21 Aug 2018 16:52:19 +0200
From:   Michal Kubecek <>
To:     Andrew Lunn <>
        Jiri Pirko <>,
        David Miller <>,
        Florian Fainelli <>,
        Roopa Prabhu <>,
        Jakub Kicinski <>,
        "John W. Linville" <>
Subject: Re: [RFC PATCH net-next v2 10/17] ethtool: implement GET_SETTINGS

On Tue, Aug 21, 2018 at 04:10:22PM +0200, Andrew Lunn wrote:
> On Tue, Aug 21, 2018 at 11:32:46AM +0200, Michal Kubecek wrote:
> > I have prepared a patch converting 8390/etherh driver to use
> > {g,s}et_link_ksettings and I'm going to submit it when net-next opens.
> > Do you think we can then drop {g,s}et_settings callbacks completely
> > (i.e. also from ioctl() code and ethtool_ops)?  Do we care about
> > unconverted out of tree drivers?
> We cannot break ethtool, the ABI it uses. But there is already code to
> use get_link_ksettings() and only fall back to get_settings if it does
> not exist. So we can clean up all the fallback code, remove the
> ethtool_ops, etc.

Yes, that's what I have in mind: keep the ethtool interface as is (both
ETHTOOL_{G,S}SET and ETHTOOL_{G,S}LINKSETTINGS) but drop get_settings
and set_settings from ethtool_ops and the code that falls back to them.
This way both old and new versions of ethtool would still work and the
only problem would be with out of tree drivers not converted to
{s,g}et_link_ksettings (which won't build so that it won't be silent

Michal Kubecek

Powered by blists - more mailing lists