2023-11-03 13:10:48

by Łukasz Bartosik

[permalink] [raw]
Subject: [PATCH v1 05/12] tracefs: add TP_printk_no_nl - RFC

From: Jim Cromie <[email protected]>

This variant of TP_printk() does *not* add the trailing newline. It
is for use by printk/debug-ish events which already have a trailing
newline. Its here to support:

https://lore.kernel.org/lkml/
[email protected]/
which taught dyndbg to send pr_debug() msgs to tracefs, via -x/T flag.

It "reused" the include/trace/events/printk.h console event,
which does the following:

TP_fast_assign(
/*
* Each trace entry is printed in a new line.
* If the msg finishes with '\n', cut it off
* to avoid blank lines in the trace.
*/
if ((len > 0) && (text[len-1] == '\n'))
len -= 1;

memcpy(__get_str(msg), text, len);
__get_str(msg)[len] = 0;
),

That trim work could be avoided, *iff* all pr_debug() callers are
known to have no '\n' to strip. While thats not true for *all*
callsites, it is 99+% true for DRM.debug callsites, and can be made
true for some subsets of prdbg/dyndbg callsites.

WANTED: macros to validate that a literal format-str has or doesn't
have a trailing newline, or to provide or trim trailing newline(s?).
Should be usable in TP_printk* defns, for use in new event defns.

Cc: <[email protected]>
Cc: Vincent Whitchurch <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: Simon Ser <[email protected]>
Cc: Sean Paul <[email protected]>
Signed-off-by: Jim Cromie <[email protected]>
---
include/trace/stages/stage3_trace_output.h | 3 +++
include/trace/stages/stage7_class_define.h | 3 +++
2 files changed, 6 insertions(+)

diff --git a/include/trace/stages/stage3_trace_output.h b/include/trace/stages/stage3_trace_output.h
index c1fb1355d309..5f5c1374fa10 100644
--- a/include/trace/stages/stage3_trace_output.h
+++ b/include/trace/stages/stage3_trace_output.h
@@ -8,6 +8,9 @@
#undef TP_printk
#define TP_printk(fmt, args...) fmt "\n", args

+#undef TP_printk_no_nl
+#define TP_printk_no_nl(fmt, args...) fmt, args
+
#undef __get_dynamic_array
#define __get_dynamic_array(field) \
((void *)__entry + (__entry->__data_loc_##field & 0xffff))
diff --git a/include/trace/stages/stage7_class_define.h b/include/trace/stages/stage7_class_define.h
index bcb960d16fc0..8247e4478f19 100644
--- a/include/trace/stages/stage7_class_define.h
+++ b/include/trace/stages/stage7_class_define.h
@@ -37,3 +37,6 @@

#undef TP_printk
#define TP_printk(fmt, args...) "\"" fmt "\", " __stringify(args)
+
+#undef TP_printk_no_nl
+#define TP_printk_no_nl(fmt, args...) "\"" fmt "\", " __stringify(args)
--
2.42.0.869.gea05f2083d-goog


2023-11-04 03:42:59

by Jim Cromie

[permalink] [raw]
Subject: Re: [PATCH v1 05/12] tracefs: add TP_printk_no_nl - RFC

On Fri, Nov 3, 2023 at 7:10 AM Łukasz Bartosik <[email protected]> wrote:
>
> From: Jim Cromie <[email protected]>
>
> This variant of TP_printk() does *not* add the trailing newline. It
> is for use by printk/debug-ish events which already have a trailing
> newline. Its here to support:
>
> https://lore.kernel.org/lkml/
> [email protected]/
> which taught dyndbg to send pr_debug() msgs to tracefs, via -x/T flag.
>
> It "reused" the include/trace/events/printk.h console event,
> which does the following:
>
> TP_fast_assign(
> /*
> * Each trace entry is printed in a new line.
> * If the msg finishes with '\n', cut it off
> * to avoid blank lines in the trace.
> */
> if ((len > 0) && (text[len-1] == '\n'))
> len -= 1;
>
> memcpy(__get_str(msg), text, len);
> __get_str(msg)[len] = 0;
> ),
>
> That trim work could be avoided, *iff* all pr_debug() callers are
> known to have no '\n' to strip. While thats not true for *all*
> callsites, it is 99+% true for DRM.debug callsites, and can be made
> true for some subsets of prdbg/dyndbg callsites.

some or all of DRM.debug messages (that I audited / caught)
were merged by Maxime recently, I;ll go back (later) to see if I missed any.

>
> WANTED: macros to validate that a literal format-str has or doesn't
> have a trailing newline, or to provide or trim trailing newline(s?).
> Should be usable in TP_printk* defns, for use in new event defns.

that might be over-optimizing

Steve,
IIRC you considered adding \n where needed.
is there anything gained (conceivably) by not just adding the trailing
\n when "needed" ?
statistically, macros could get us to 99.99+ "compliance"
IIRC - the "needed" seems correct.


>
> Cc: <[email protected]>
> Cc: Vincent Whitchurch <[email protected]>
> Cc: <[email protected]>
> Cc: <[email protected]>
> Cc: <[email protected]>
> Cc: <[email protected]>
> Cc: Simon Ser <[email protected]>
> Cc: Sean Paul <[email protected]>
> Signed-off-by: Jim Cromie <[email protected]>
> ---
> include/trace/stages/stage3_trace_output.h | 3 +++
> include/trace/stages/stage7_class_define.h | 3 +++
> 2 files changed, 6 insertions(+)
>
> diff --git a/include/trace/stages/stage3_trace_output.h b/include/trace/stages/stage3_trace_output.h
> index c1fb1355d309..5f5c1374fa10 100644
> --- a/include/trace/stages/stage3_trace_output.h
> +++ b/include/trace/stages/stage3_trace_output.h
> @@ -8,6 +8,9 @@
> #undef TP_printk
> #define TP_printk(fmt, args...) fmt "\n", args
>
> +#undef TP_printk_no_nl
> +#define TP_printk_no_nl(fmt, args...) fmt, args
> +
> #undef __get_dynamic_array
> #define __get_dynamic_array(field) \
> ((void *)__entry + (__entry->__data_loc_##field & 0xffff))
> diff --git a/include/trace/stages/stage7_class_define.h b/include/trace/stages/stage7_class_define.h
> index bcb960d16fc0..8247e4478f19 100644
> --- a/include/trace/stages/stage7_class_define.h
> +++ b/include/trace/stages/stage7_class_define.h
> @@ -37,3 +37,6 @@
>
> #undef TP_printk
> #define TP_printk(fmt, args...) "\"" fmt "\", " __stringify(args)
> +
> +#undef TP_printk_no_nl
> +#define TP_printk_no_nl(fmt, args...) "\"" fmt "\", " __stringify(args)
> --
> 2.42.0.869.gea05f2083d-goog
>

2023-11-07 01:42:36

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH v1 05/12] tracefs: add TP_printk_no_nl - RFC

On Fri, 3 Nov 2023 21:40:13 -0600
[email protected] wrote:

> Steve,
> IIRC you considered adding \n where needed.
> is there anything gained (conceivably) by not just adding the trailing
> \n when "needed" ?
> statistically, macros could get us to 99.99+ "compliance"
> IIRC - the "needed" seems correct.
>

I replied to the next patch suggesting to do this on the read side.

-- Steve