From: Jakub Kicinski <kuba@kernel.org>
To: Jamal Hadi Salim <jhs@mojatatu.com>
Cc: Pedro Tammela <pctammela@mojatatu.com>,
netdev@vger.kernel.org, xiyou.wangcong@gmail.com,
jiri@resnulli.us, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com
Subject: Re: [PATCH net-next 1/2] net/sched: sch_htb: use extack on errors messages
Date: Mon, 17 Apr 2023 08:52:51 -0700 [thread overview]
Message-ID: <20230417085251.6b031b1e@kernel.org> (raw)
In-Reply-To: <CAM0EoMkYCZovRqu4KRvgoO0YfEf0UXm0tU_uTmfJ5Ln2kbD1mQ@mail.gmail.com>
On Sat, 15 Apr 2023 10:06:36 -0400 Jamal Hadi Salim wrote:
> There is no "rule" other than the LinuxWay(tm) i.e. people cutnpaste.
:-)
> It's not just on qdiscs that this inconsistency exists but also on
> filters and actions.
> Do we need a rule to prefer one over the other? _MOD() seems to
> provide more information - which is always useful.
People started adding _MOD() on every extack so I was pushing back
a little lately. It will bloat the strings and makes the output between
parsing and hand coded checks different. Plus if we really want the
mod name, we should just make it the default and remove the non-mod
version.
The rule of thumb I had was that if the message comes from "core" of
a family then _MOD() is unnecessary. In this case HTB is a one-of-many
implementations so _MOD() seems fine. Then again errors about parsing
TCA_HTB_* attrs are unlikely to come from something else than HTB..
next prev parent reply other threads:[~2023-04-17 15:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-14 18:53 [PATCH net-next 0/2] net/sched: cleanup parsing prints in htb and qfq Pedro Tammela
2023-04-14 18:53 ` [PATCH net-next 1/2] net/sched: sch_htb: use extack on errors messages Pedro Tammela
2023-04-15 1:13 ` Jakub Kicinski
2023-04-15 14:06 ` Jamal Hadi Salim
2023-04-17 15:52 ` Jakub Kicinski [this message]
2023-04-17 16:35 ` Pedro Tammela
2023-04-14 18:53 ` [PATCH net-next 2/2] net/sched: sch_qfq: " Pedro Tammela
2023-04-15 1:15 ` Jakub Kicinski
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=20230417085251.6b031b1e@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pctammela@mojatatu.com \
--cc=xiyou.wangcong@gmail.com \
/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).