linux-kernel - Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)

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: <20171211163246.GC1885@nanopsycho>
Date:   Mon, 11 Dec 2017 17:32:46 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Michal Kubecek <mkubecek@...e.cz>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)

Mon, Dec 11, 2017 at 02:53:11PM CET, mkubecek@...e.cz wrote:
>This is still work in progress and only a very small part of the ioctl
>interface is reimplemented but I would like to get some comments before
>the patchset becomes too big and changing things becomes too tedious.
>
>The interface used for communication between ethtool and kernel is based on
>ioctl() and suffers from many problems. The most pressing seems the be the
>lack of extensibility. While some of the newer commands use structures
>designed to allow future extensions (e.g. GFEATURES or TEST), most either
>allow no extension at all (GPAUSEPARAM, GCOALESCE) or only limited set of
>reserved fields (GDRVINFO, GEEE). Even most of those which support future
>extensions limit the data types that can be used.
>
>This series aims to provide an alternative interface based on netlink which
>is what other network configuration utilities use. In particular, it uses
>generic netlink (family "ethtool"). The goal is to provide an interface
>which would be extensible, flexible and practical both for ethtool and for
>other network configuration tools (e.g. wicked or systemd-networkd).
>
>The interface is documented in Documentation/networking/ethtool-netlink.txt
>
>I'll post RFC patch series for ethtool in a few days, it still needs some
>more polishing.

First of all, thank you Michale for taking a stab at this!

I think that it does not make sense to convert ethtool->netlink_ethtool
1:1 feature wise. Now we have devlink, ritch switch representation
model, tc offload and many others. Lot of things that are in
ethtool, should be done in devlink. Also, there are couple of things
that should just die - nice example is ethtool --config-ntuple - we
should use tc for that.

So I believe that it would be better to introduce new iterface called
differently, to avoid confusion, like "ethlink" and start to migrate
things there, without existing baggage. In kernel the existing ethtool
would just call compat layer inside ethlink code. Similarly with devlink.
ethtool api would freeze. Similar scenario to rtnetlink and legacy ioctl.

Also, this new netlink iface should have userspace notification
support from day 1.