remove unnecessary logspam
Commit Message
This patch removes unnecessary logspam which resulted from superfluous
calls to net_ratelimit(). With the supplied patch, net_ratelimit() is
called after the loglevel has been checked.
Signed-off-by: André Gaul <gaul@web-yard.de>
---
main.h | 20 ++++++++++++++------
routing.c | 18 +++++++++---------
2 files changed, 23 insertions(+), 15 deletions(-)
Comments
On 09/06/14 19:14, André Gaul wrote:
> This patch removes unnecessary logspam which resulted from superfluous
> calls to net_ratelimit(). With the supplied patch, net_ratelimit() is
> called after the loglevel has been checked.
>
> Signed-off-by: André Gaul <gaul@web-yard.de>
André,
I'd suggest you to check this patch with checkpatch.pl --strict. Here I
get many errors due to non-printable chars at the end of various lines.
Here[1] you find our guidelines (which is a set of complementary rules
to the guidelines you find in the kernel tree[2]).
Moreover, the subject must start with "batman-adv: ", because this patch
will end up in the kernel and it requires this format to easily
distinguish the subsystem that the patch is touching.
A couple of things to keep in mind while sending new versions of the
same patch:
- don't reply to an existing thread
- write [PATCHvN] (with N = version of the patch - 2 in this case) in
the subject
Cheers,
[1]
http://www.open-mesh.org/projects/open-mesh/wiki/Contribute#Submitting-patches
[2]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches
Hey Antonio,
thx for your quick reply!
Am 09.06.2014 23:05, schrieb Antonio Quartulli:
> I'd suggest you to check this patch with checkpatch.pl --strict. Here I
> get many errors due to non-printable chars at the end of various lines.
I did that and I don't get any errors or warnings with checkpatch.pl
--strict. It tells me:
------
$ ./scripts/checkpatch.pl --strict
/tmp/0001-remove-unnecessary-logspam.patch
total: 0 errors, 0 warnings, 65 lines checked
/tmp/0001-remove-unnecessary-logspam.patch has no obvious style problems
and is ready for submission.
------
> Here[1] you find our guidelines (which is a set of complementary rules
> to the guidelines you find in the kernel tree[2]).
>
> Moreover, the subject must start with "batman-adv: ", because this patch
> will end up in the kernel and it requires this format to easily
> distinguish the subsystem that the patch is touching.
>
> A couple of things to keep in mind while sending new versions of the
> same patch:
> - don't reply to an existing thread
> - write [PATCHvN] (with N = version of the patch - 2 in this case) in
> the subject
OK, I can resubmit with the corrected subject line
[PATCHv2] batman-adv: remove unnecessary logspam
but I'd like to know first what this non-printable chars issue is about.
cheers,
André
Hi André,
On 09/06/14 23:36, André Gaul wrote:
> Hey Antonio,
>
> thx for your quick reply!
>
> Am 09.06.2014 23:05, schrieb Antonio Quartulli:
>> I'd suggest you to check this patch with checkpatch.pl --strict. Here I
>> get many errors due to non-printable chars at the end of various lines.
>
This is my output (this is checkpatch from net-next) - you can ignore
the warnings about "Macros with complex values should be enclosed in
parenthesis":
$ ./exp/linux-merge/scripts/checkpatch.pl --strict \[B.A.T.M.A.N.\]\
\[PATCH\]\ remove\ unnecessary\ logspam.eml
ERROR: DOS line endings
#111: FILE: main.h:242:
+/* possibly ratelimited debug output */^M$
ERROR: DOS line endings
#112: FILE: main.h:243:
+#define _batadv_dbg(type, bat_priv, ratelimited, fmt, arg...)^I\^M$
WARNING: Whitespace after \ makes next lines useless
#112: FILE: main.h:243:
+#define _batadv_dbg(type, bat_priv, ratelimited, fmt, arg...) \
ERROR: Macros with complex values should be enclosed in parenthesis
#112: FILE: main.h:243:
+#define _batadv_dbg(type, bat_priv, ratelimited, fmt, arg...) \
ERROR: DOS line endings
#115: FILE: main.h:245:
+^I^Iif (atomic_read(&bat_priv->log_level) & type && \^M$
ERROR: DOS line endings
#116: FILE: main.h:246:
+^I^I (!ratelimited || net_ratelimit()))^I^I\^M$
ERROR: DOS line endings
#125: FILE: main.h:251:
+__printf(4, 5)^M$
ERROR: DOS line endings
#126: FILE: main.h:252:
+static inline void _batadv_dbg(int type __always_unused,^M$
ERROR: DOS line endings
#127: FILE: main.h:253:
+^I^I^I struct batadv_priv *bat_priv __always_unused,^M$
ERROR: DOS line endings
#128: FILE: main.h:254:
+^I^I^I int ratelimited __always_unused,^M$
ERROR: DOS line endings
#129: FILE: main.h:255:
+^I^I^I const char *fmt __always_unused, ...)^M$
ERROR: DOS line endings
#134: FILE: main.h:260:
+#define batadv_dbg(type, bat_priv, arg...) \^M$
WARNING: Whitespace after \ makes next lines useless
#134: FILE: main.h:260:
+#define batadv_dbg(type, bat_priv, arg...) \
ERROR: Macros with complex values should be enclosed in parenthesis
#134: FILE: main.h:260:
+#define batadv_dbg(type, bat_priv, arg...) \
ERROR: DOS line endings
#135: FILE: main.h:261:
+^I_batadv_dbg(type, bat_priv, 0, ## arg)^M$
ERROR: DOS line endings
#136: FILE: main.h:262:
+#define batadv_dbg_ratelimited(type, bat_priv, arg...) \^M$
WARNING: Whitespace after \ makes next lines useless
#136: FILE: main.h:262:
+#define batadv_dbg_ratelimited(type, bat_priv, arg...) \
ERROR: Macros with complex values should be enclosed in parenthesis
#136: FILE: main.h:262:
+#define batadv_dbg_ratelimited(type, bat_priv, arg...) \
ERROR: DOS line endings
#137: FILE: main.h:263:
+^I_batadv_dbg(type, bat_priv, 1, ## arg)^M$
ERROR: DOS line endings
#138: FILE: main.h:264:
+^M$
ERROR: DOS line endings
#155: FILE: routing.c:709:
+^I^I^Ibatadv_dbg_ratelimited(BATADV_DBG_TT,^M$
ERROR: DOS line endings
#156: FILE: routing.c:710:
+^I^I^I^I^I bat_priv,^M$
ERROR: DOS line endings
#157: FILE: routing.c:711:
+^I^I^I^I^I "Rerouting unicast packet to %pM (dst=%pM): Local
Roaming\n",^M$
ERROR: DOS line endings
#158: FILE: routing.c:712:
+^I^I^I^I^I unicast_packet->dest,^M$
ERROR: DOS line endings
#159: FILE: routing.c:713:
+^I^I^I^I^I ethhdr->h_dest);^M$
ERROR: DOS line endings
#171: FILE: routing.c:755:
+^I^Ibatadv_dbg_ratelimited(BATADV_DBG_TT, bat_priv,^M$
ERROR: DOS line endings
#172: FILE: routing.c:756:
+^I^I^I^I "Rerouting unicast packet to %pM (dst=%pM): TTVN
mismatch old_ttvn=%u new_ttvn=%u\n",^M$
ERROR: DOS line endings
#173: FILE: routing.c:757:
+^I^I^I^I unicast_packet->dest, ethhdr->h_dest,^M$
ERROR: DOS line endings
#174: FILE: routing.c:758:
+^I^I^I^I old_ttvn, curr_ttvn);^M$
total: 26 errors, 3 warnings, 0 checks, 65 lines checked
[B.A.T.M.A.N.] [PATCH] remove unnecessary logspam.eml has style
problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
maybe it's the mail client that messes the patch up? Are you using
git-send-email ?
Cheers,
Hi Antonio!
Am 10.06.2014 08:01, schrieb Antonio Quartulli:
> maybe it's the mail client that messes the patch up? Are you using
> git-send-email ?
Yep, it's git-send-email. Maybe you are running into this mbox/eml issue
[1]? Thunderbird seems to save plain text files with DOS line endings
when saved as .eml. I can reproduce the errors you got with an .eml
file. When saving as .txt it has the correct line endings and the
checkpatch script gives no errors or warnings.
If this resolves the issue with the DOS line endings, I'd resubmit with
the corrected subject line.
Cheers,
André
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=523577
Hi André,
On 10/06/14 17:38, André Gaul wrote:
> Hi Antonio!
>
> Am 10.06.2014 08:01, schrieb Antonio Quartulli:
>> maybe it's the mail client that messes the patch up? Are you using
>> git-send-email ?
>
> Yep, it's git-send-email. Maybe you are running into this mbox/eml issue
> [1]? Thunderbird seems to save plain text files with DOS line endings
> when saved as .eml. I can reproduce the errors you got with an .eml
> file. When saving as .txt it has the correct line endings and the
> checkpatch script gives no errors or warnings.
>
> If this resolves the issue with the DOS line endings, I'd resubmit with
> the corrected subject line.
>
Oh you are right. I should have continued using mutt...
Thanks! :)
Am 10.06.2014 17:40, schrieb Antonio Quartulli:
> Oh you are right. I should have continued using mutt...
hehe, I'm glad it works now! :) I'll resubmit in a minute as a new thread.
btw: do you have any pointers to documentation that can help me
understand why the kernel developers still use email as the primary
channel for submitting patches? Given the fact that git gracefully
handles the transmission of code, the handling of all code via email
appears archaic and too complicated to me. (no flame war intended, I
just want to learn about the reasons!) ;)
Cheers,
André
On 10/06/14 17:45, André Gaul wrote:
> Am 10.06.2014 17:40, schrieb Antonio Quartulli:
>> Oh you are right. I should have continued using mutt...
>
> hehe, I'm glad it works now! :) I'll resubmit in a minute as a new thread.
>
> btw: do you have any pointers to documentation that can help me
> understand why the kernel developers still use email as the primary
> channel for submitting patches? Given the fact that git gracefully
> handles the transmission of code, the handling of all code via email
> appears archaic and too complicated to me. (no flame war intended, I
> just want to learn about the reasons!) ;)
Honestly I don't know if there is any documentation.
Sending a patch to a mailing list is a way to ask for a
review/evaluation, which works well so I don't see a clear reason why it
should be changed (just that it appears archaic does not seem to be a
good reason).
Only maintainer having their tree on a trusted host can send pull
requests without attaching the patches (we do send pull requests along
with the patches exactly for this reason..).
And actually git also provides many comfortable commands to do that :)
so...! :)
Cheers,
On Tuesday 10 June 2014 17:45:17 André Gaul wrote:
> btw: do you have any pointers to documentation that can help me
> understand why the kernel developers still use email as the primary
> channel for submitting patches? Given the fact that git gracefully
> handles the transmission of code, the handling of all code via email
> appears archaic and too complicated to me. (no flame war intended, I
> just want to learn about the reasons!) ;)
Traditionally, patches on the mailing list make it easy to review & comment
patches by everyone.
What is the alternative you have in mind (no vendor lock-in please) ?
Cheers,
Marek
@@ -239,21 +239,29 @@ enum batadv_dbg_level {
int batadv_debug_log(struct batadv_priv *bat_priv, const char *fmt, ...)
__printf(2, 3);
-#define batadv_dbg(type, bat_priv, fmt, arg...) \
+/* possibly ratelimited debug output */
+#define _batadv_dbg(type, bat_priv, ratelimited, fmt, arg...) \
do { \
- if (atomic_read(&bat_priv->log_level) & type) \
+ if (atomic_read(&bat_priv->log_level) & type && \
+ (!ratelimited || net_ratelimit())) \
batadv_debug_log(bat_priv, fmt, ## arg);\
} \
while (0)
#else /* !CONFIG_BATMAN_ADV_DEBUG */
-__printf(3, 4)
-static inline void batadv_dbg(int type __always_unused,
- struct batadv_priv *bat_priv __always_unused,
- const char *fmt __always_unused, ...)
+__printf(4, 5)
+static inline void _batadv_dbg(int type __always_unused,
+ struct batadv_priv *bat_priv __always_unused,
+ int ratelimited __always_unused,
+ const char *fmt __always_unused, ...)
{
}
#endif
+#define batadv_dbg(type, bat_priv, arg...) \
+ _batadv_dbg(type, bat_priv, 0, ## arg)
+#define batadv_dbg_ratelimited(type, bat_priv, arg...) \
+ _batadv_dbg(type, bat_priv, 1, ## arg)
+
#define batadv_info(net_dev, fmt, arg...) \
do { \
struct net_device *_netdev = (net_dev); \
@@ -706,11 +706,11 @@ static int batadv_check_unicast_ttvn(struct batadv_priv *bat_priv,
if (batadv_tt_local_client_is_roaming(bat_priv, ethhdr->h_dest, vid)) {
if (batadv_reroute_unicast_packet(bat_priv, unicast_packet,
ethhdr->h_dest, vid))
- net_ratelimited_function(batadv_dbg, BATADV_DBG_TT,
- bat_priv,
- "Rerouting unicast packet to %pM (dst=%pM): Local Roaming\n",
- unicast_packet->dest,
- ethhdr->h_dest);
+ batadv_dbg_ratelimited(BATADV_DBG_TT,
+ bat_priv,
+ "Rerouting unicast packet to %pM (dst=%pM): Local Roaming\n",
+ unicast_packet->dest,
+ ethhdr->h_dest);
/* at this point the mesh destination should have been
* substituted with the originator address found in the global
* table. If not, let the packet go untouched anyway because
@@ -752,10 +752,10 @@ static int batadv_check_unicast_ttvn(struct batadv_priv *bat_priv,
*/
if (batadv_reroute_unicast_packet(bat_priv, unicast_packet,
ethhdr->h_dest, vid)) {
- net_ratelimited_function(batadv_dbg, BATADV_DBG_TT, bat_priv,
- "Rerouting unicast packet to %pM (dst=%pM): TTVN mismatch old_ttvn=%u new_ttvn=%u\n",
- unicast_packet->dest, ethhdr->h_dest,
- old_ttvn, curr_ttvn);
+ batadv_dbg_ratelimited(BATADV_DBG_TT, bat_priv,
+ "Rerouting unicast packet to %pM (dst=%pM): TTVN mismatch old_ttvn=%u new_ttvn=%u\n",
+ unicast_packet->dest, ethhdr->h_dest,
+ old_ttvn, curr_ttvn);
return 1;
}