From: David Miller <davem@davemloft.net>
To: johannes@sipsolutions.net
Cc: greearb@candelatech.com, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH 1/3] ethtool: Support ETHTOOL_GSTATS2 command.
Date: Sun, 22 Apr 2018 14:54:20 -0400 (EDT) [thread overview]
Message-ID: <20180422.145420.1197041027922699603.davem@davemloft.net> (raw)
In-Reply-To: <1524151617.3024.25.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 19 Apr 2018 17:26:57 +0200
> On Thu, 2018-04-19 at 08:25 -0700, Ben Greear wrote:
>>
>> Maybe this could be in followup patches? It's going to touch a lot of files,
>> and might be hell to get merged all at once, and I've never used spatch, so
>> just maybe someone else will volunteer that part :)
>
> I guess you'll have to ask davem. :)
Well, first of all, I really don't like this.
The first reason is that every time I see interface foo become foo2,
foo3 is never far behind it.
If foo was not extensible enough such that we needed foo2, we beter
design the new thing with explicitly better extensibility in mind.
Furthermore, what you want here is a specific filter. Someone else
will want to filter on another criteria, and the next person will
want yet another.
This needs to be properly generalized.
And frankly if we had moved to ethtool netlink/devlink by now, we
could just add a netlink attribute for filtering and not even be
having this conversation.
WARNING: multiple messages have this Message-ID (diff)
From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
To: johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org
Cc: greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 1/3] ethtool: Support ETHTOOL_GSTATS2 command.
Date: Sun, 22 Apr 2018 14:54:20 -0400 (EDT) [thread overview]
Message-ID: <20180422.145420.1197041027922699603.davem@davemloft.net> (raw)
In-Reply-To: <1524151617.3024.25.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Thu, 19 Apr 2018 17:26:57 +0200
> On Thu, 2018-04-19 at 08:25 -0700, Ben Greear wrote:
>>
>> Maybe this could be in followup patches? It's going to touch a lot of files,
>> and might be hell to get merged all at once, and I've never used spatch, so
>> just maybe someone else will volunteer that part :)
>
> I guess you'll have to ask davem. :)
Well, first of all, I really don't like this.
The first reason is that every time I see interface foo become foo2,
foo3 is never far behind it.
If foo was not extensible enough such that we needed foo2, we beter
design the new thing with explicitly better extensibility in mind.
Furthermore, what you want here is a specific filter. Someone else
will want to filter on another criteria, and the next person will
want yet another.
This needs to be properly generalized.
And frankly if we had moved to ethtool netlink/devlink by now, we
could just add a netlink attribute for filtering and not even be
having this conversation.
WARNING: multiple messages have this Message-ID (diff)
From: David Miller <davem@davemloft.net>
To: johannes@sipsolutions.net
Cc: netdev@vger.kernel.org, greearb@candelatech.com,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH 1/3] ethtool: Support ETHTOOL_GSTATS2 command.
Date: Sun, 22 Apr 2018 14:54:20 -0400 (EDT) [thread overview]
Message-ID: <20180422.145420.1197041027922699603.davem@davemloft.net> (raw)
In-Reply-To: <1524151617.3024.25.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 19 Apr 2018 17:26:57 +0200
> On Thu, 2018-04-19 at 08:25 -0700, Ben Greear wrote:
>>
>> Maybe this could be in followup patches? It's going to touch a lot of files,
>> and might be hell to get merged all at once, and I've never used spatch, so
>> just maybe someone else will volunteer that part :)
>
> I guess you'll have to ask davem. :)
Well, first of all, I really don't like this.
The first reason is that every time I see interface foo become foo2,
foo3 is never far behind it.
If foo was not extensible enough such that we needed foo2, we beter
design the new thing with explicitly better extensibility in mind.
Furthermore, what you want here is a specific filter. Someone else
will want to filter on another criteria, and the next person will
want yet another.
This needs to be properly generalized.
And frankly if we had moved to ethtool netlink/devlink by now, we
could just add a netlink attribute for filtering and not even be
having this conversation.
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2018-04-22 18:54 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-18 1:49 [PATCH 1/3] ethtool: Support ETHTOOL_GSTATS2 command greearb
2018-04-18 1:49 ` greearb
2018-04-18 1:49 ` greearb-my8/4N5VtI7c+919tysfdA
2018-04-18 1:49 ` [PATCH 2/3] mac80211: Add support for ethtool gstats2 API greearb
2018-04-18 1:49 ` greearb
2018-04-18 1:49 ` [PATCH 3/3] ath10k: Support " greearb
2018-04-18 1:49 ` greearb
2018-04-19 11:19 ` kbuild test robot
2018-04-19 11:19 ` kbuild test robot
2018-04-18 21:07 ` [PATCH 1/3] ethtool: Support ETHTOOL_GSTATS2 command Florian Fainelli
2018-04-18 21:07 ` Florian Fainelli
2018-04-18 21:26 ` Johannes Berg
2018-04-18 21:26 ` Johannes Berg
2018-04-18 21:51 ` Ben Greear
2018-04-18 21:51 ` Ben Greear
2018-04-19 6:38 ` Johannes Berg
2018-04-19 6:38 ` Johannes Berg
2018-04-19 15:25 ` Ben Greear
2018-04-19 15:25 ` Ben Greear
2018-04-19 15:26 ` Johannes Berg
2018-04-19 15:26 ` Johannes Berg
2018-04-19 15:26 ` Johannes Berg
2018-04-22 18:54 ` David Miller [this message]
2018-04-22 18:54 ` David Miller
2018-04-22 18:54 ` David Miller
2018-04-22 21:15 ` Roopa Prabhu
2018-04-22 21:15 ` Roopa Prabhu
2018-04-22 21:15 ` Roopa Prabhu
2018-04-23 15:41 ` Ben Greear
2018-04-23 15:41 ` Ben Greear
2018-04-23 15:38 ` Ben Greear
2018-04-23 15:38 ` Ben Greear
2018-04-23 15:38 ` Ben Greear
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=20180422.145420.1197041027922699603.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=ath10k@lists.infradead.org \
--cc=greearb@candelatech.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.