netdev - Re: As usage of ethtool private flags is deprecated, what should we use from now on?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ca6833e7-2d04-4dcd-9f8b-cab2c2f16183@lunn.ch>
Date: Tue, 9 May 2023 15:26:06 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Sokolowski, Jan" <jan.sokolowski@...el.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: As usage of ethtool private flags is deprecated, what should we
 use from now on?

On Tue, May 09, 2023 at 11:15:57AM +0000, Sokolowski, Jan wrote:
> Hello netdev!
> 
> So, as recently I've been trying to upstream a patch that would introduce a new private flag to i40e driver,
> I've received a note that, according to this reply from Jakub Kicinski (https://lore.kernel.org/netdev/20230207215643.43f76bdd@kernel.org/),
> the use of private flags is deprecated and is something that will not be accepted by upstream anymore. 
> As such flags are an easy way to flip driver-specific behavior switches,
> and in the future there would be more patches written to allow end-users to change how the driver works,
> it appears that a new way forward is required.

Hi Jan

Is your device 'special'. Does it do things which no other device
does? Why is it doing something which no other device does? Surely if
it is useful, others will copy it. If nobody is going to copy it, then
you have to wonder if it has any value, and why should we care about
it.

We much prefer generic solutions to problem which can be used for a
number of devices. So please consider if this a generic configuration
knob which multiple drivers could make use of? If it is, add a well
defined, documented API for it, using netlink, as part of ethtool or
iproute2, etc. And then watch others coping the idea into their
driver, making use of the API you just added. Everybody benefits.

	Andrew