From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
Andrew Lunn <andrew@lunn.ch>, Jiri Pirko <jiri@resnulli.us>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH net-next v3 13/21] ethtool: provide timestamping information in GET_INFO request
Date: Wed, 20 Feb 2019 10:37:09 -0800 [thread overview]
Message-ID: <20190220103709.122260d6@cakuba.netronome.com> (raw)
In-Reply-To: <20190220130007.GI23151@unicorn.suse.cz>
On Wed, 20 Feb 2019 14:00:07 +0100, Michal Kubecek wrote:
> On Tue, Feb 19, 2019 at 07:00:48PM -0800, Jakub Kicinski wrote:
> > On Mon, 18 Feb 2019 19:22:29 +0100 (CET), Michal Kubecek wrote:
> > > Add timestamping information as provided by ETHTOOL_GET_TS_INFO ioctl
> > > command in GET_INFO reply if ETH_INFO_IM_TSINFO flag is set in the request.
> > >
> > > Add constants for counts of HWTSTAMP_TX_* and HWTSTAM_FILTER_* constants
> > > and provide symbolic names for timestamping related values so that they can
> > > be retrieved in GET_STRSET and GET_INFO requests.
> >
> > What's the reason for providing the symbolic names?
>
> One of the the goals I had was to reduce the need to keep the lists of
> possible values in sync between kernel and userspace ethtool and other
> users of the interface so that when a new value is added, we don't have
> to update all userspace tools to be able to use or present it.
>
> This already works in ethtool for some newer commands (e.g. features)
> and obviously for those where the list of available options depends on
> the device (e.g. private flags or statistics). I would like to extend
> the principle also to older commands and new ones which do not work like
> this (e.g. device reset).
Let me try to argue that's the wrong direction. People should learn to
update their user space tooling if they want access to new features.
In my (limited) experience trying to solve forward compatibility leads
to short term gains, and long term warts in the APIs and increased
maintenance burden in the kernel.
next prev parent reply other threads:[~2019-02-20 18:37 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-18 18:21 [RFC PATCH net-next v3 00/21] ethtool netlink interface, part 1 Michal Kubecek
2019-02-18 18:21 ` [RFC PATCH net-next v3 01/21] netlink: introduce nla_put_bitfield32() Michal Kubecek
2019-02-18 18:21 ` [RFC PATCH net-next v3 02/21] ethtool: move to its own directory Michal Kubecek
2019-02-18 20:01 ` Jakub Kicinski
2019-02-18 18:21 ` [RFC PATCH net-next v3 03/21] ethtool: introduce ethtool netlink interface Michal Kubecek
2019-02-18 18:21 ` [RFC PATCH net-next v3 04/21] ethtool: helper functions for " Michal Kubecek
2019-02-18 20:15 ` Jakub Kicinski
2019-02-19 13:07 ` Michal Kubecek
2019-02-18 18:21 ` [RFC PATCH net-next v3 05/21] ethtool: netlink bitset handling Michal Kubecek
2019-02-20 2:27 ` Jakub Kicinski
2019-02-20 8:16 ` Michal Kubecek
2019-02-18 18:21 ` [RFC PATCH net-next v3 06/21] ethtool: support for netlink notifications Michal Kubecek
2019-02-18 18:21 ` [RFC PATCH net-next v3 07/21] ethtool: implement EVENT notifications Michal Kubecek
2019-02-18 23:46 ` Andrew Lunn
2019-02-19 7:02 ` Michal Kubecek
2019-02-18 18:22 ` [RFC PATCH net-next v3 08/21] ethtool: generic handlers for GET requests Michal Kubecek
2019-02-20 2:42 ` Jakub Kicinski
2019-02-18 18:22 ` [RFC PATCH net-next v3 09/21] ethtool: move string arrays into common file Michal Kubecek
2019-02-18 18:22 ` [RFC PATCH net-next v3 10/21] ethtool: provide string sets with GET_STRSET request Michal Kubecek
2019-02-20 2:56 ` Jakub Kicinski
2019-02-20 12:34 ` Michal Kubecek
2019-02-18 18:22 ` [RFC PATCH net-next v3 11/21] ethtool: provide driver/device information in GET_INFO request Michal Kubecek
2019-02-18 18:22 ` [RFC PATCH net-next v3 12/21] ethtool: provide permanent hardware address " Michal Kubecek
2019-02-19 10:24 ` Jiri Pirko
2019-02-19 11:36 ` Michal Kubecek
2019-02-18 18:22 ` [RFC PATCH net-next v3 13/21] ethtool: provide timestamping information " Michal Kubecek
2019-02-20 3:00 ` Jakub Kicinski
2019-02-20 13:00 ` Michal Kubecek
2019-02-20 18:37 ` Jakub Kicinski [this message]
2019-02-18 18:22 ` [RFC PATCH net-next v3 14/21] ethtool: provide link mode names as a string set Michal Kubecek
2019-02-21 3:21 ` Florian Fainelli
2019-02-21 9:57 ` Michal Kubecek
2019-02-18 18:22 ` [RFC PATCH net-next v3 15/21] ethtool: provide link settings and link modes in GET_SETTINGS request Michal Kubecek
2019-02-21 3:14 ` Florian Fainelli
2019-02-21 10:14 ` Michal Kubecek
2019-02-21 17:40 ` Florian Fainelli
2019-02-18 18:22 ` [RFC PATCH net-next v3 16/21] ethtool: provide WoL information " Michal Kubecek
2019-02-18 18:22 ` [RFC PATCH net-next v3 17/21] ethtool: provide message level " Michal Kubecek
2019-02-18 18:22 ` [RFC PATCH net-next v3 18/21] ethtool: provide link state " Michal Kubecek
2019-02-18 18:23 ` [RFC PATCH net-next v3 19/21] ethtool: provide device features " Michal Kubecek
2019-02-18 18:23 ` [RFC PATCH net-next v3 20/21] ethtool: provide private flags " Michal Kubecek
2019-02-18 18:23 ` [RFC PATCH net-next v3 21/21] ethtool: send netlink notifications about setting changes Michal Kubecek
2019-02-19 10:35 ` [RFC PATCH net-next v3 00/21] ethtool netlink interface, part 1 Jiri Pirko
2019-02-19 11:57 ` Michal Kubecek
2019-02-19 12:27 ` Jiri Pirko
2019-02-21 3:21 ` Florian Fainelli
2019-02-21 9:54 ` Michal Kubecek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190220103709.122260d6@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=jiri@resnulli.us \
--cc=linux-kernel@vger.kernel.org \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).