netdev - [RFC] ethtool: Support for driver private ioctl's

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-next>] [day] [month] [year] [list]

Date:   Thu, 5 Apr 2018 11:47:28 +0100
From:   Jose Abreu <Jose.Abreu@...opsys.com>
To:     David Miller <davem@...hat.com>, Jakub Jelinek <jj@...ra.linux.cz>,
        "Jeff Garzik" <jgarzik@...ox.com>, Tim Hockin <thockin@....com>,
        Eli Kupermann <eli.kupermann@...el.com>,
        Chris Leech <christopher.leech@...el.com>,
        "Scott Feldman" <scott.feldman@...el.com>,
        Ben Hutchings <ben@...adent.org.uk>
CC:     <netdev@...r.kernel.org>, Joao Pinto <Joao.Pinto@...opsys.com>
Subject: [RFC] ethtool: Support for driver private ioctl's

Hi All,

I would like to know your opinion regarding adding support for
driver private ioctl's in ethtool.

Background: Synopsys Ethernet IP's have a certain number of
features which can be reconfigured at runtime. Giving you two
examples: One of the most recent one is the safety features,
which can be enabled/disabled and forced at runtime. Another one
is a Flexible RX Parser which can route specific packets to
specific RX DMA channels. Given that these are features specific
to our IP's it would not be useful to add an uniform API for this
because the users would only be one or two drivers ...

This new feature would change the help usage for ethtool so that
each driver private option would be shown, and then each driver
specific file would have a structure with all the available
options. Finally, each driver would have to handle the private
IOCTL's.

We already have this working locally and now I would like to know
your opinion about upstreaming this ... Do you think this can be
useful for anyone else? Or should we change direction to use, for
example, debugfs/configfs?

Thanks and Best Regards,
Jose Miguel Abreu