[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240715063931.16bbe350@kernel.org>
Date: Mon, 15 Jul 2024 06:39:31 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: "Mogilappagari, Sudheer" <sudheer.mogilappagari@...el.com>, Michal
Kubecek <mkubecek@...e.cz>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, Wei Fang <wei.fang@....com>, "Samudrala, Sridhar"
<sridhar.samudrala@...el.com>
Subject: Re: Netlink handler for ethtool --show-rxfh breaks driver
compatibility
On Mon, 15 Jul 2024 16:22:53 +0300 Vladimir Oltean wrote:
> On Mon, Jul 15, 2024 at 06:11:37AM -0700, Jakub Kicinski wrote:
> > On Mon, 15 Jul 2024 14:58:07 +0300 Vladimir Oltean wrote:
> > > Looking at Documentation/networking/ethtool-netlink.rst, I see
> > > ETHTOOL_GRXRINGS has no netlink equivalent. So print_indir_table()
> > > should still be called with the result of the ETHTOOL_GRXRINGS ioctl
> > > even in the netlink case?
> >
> > How about we fall back to the old method if netlink returns EOPNOTSUPP
> > for CHANNELS_GET? The other API is a bit of a historic coincidence.
>
> Explain "historic coincidence" like I'm 5?
The definition I have in mind is that the design can't be well
understood without taking into account the history, i.e. the order
in which things were developed and the information we were working
with at the time.
In this case, simply put, GRXRINGS was added well before GCHANNELS
and to assign any semantic distinction between GRXRINGS and GCHANNELS
is revisionist, for lack of a better word.
I could be wrong, but that's what I meant by "historic coincidence".
Powered by blists - more mailing lists