Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755402AbaLHOzm (ORCPT ); Mon, 8 Dec 2014 09:55:42 -0500 Received: from fw-tnat.cambridge.arm.com ([217.140.96.140]:45384 "EHLO cam-smtp0.cambridge.arm.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750908AbaLHOzk (ORCPT ); Mon, 8 Dec 2014 09:55:40 -0500 X-Greylist: delayed 994 seconds by postgrey-1.27 at vger.kernel.org; Mon, 08 Dec 2014 09:55:40 EST Date: Mon, 8 Dec 2014 14:39:54 +0000 From: Dave P Martin To: Javi Merino Cc: "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Punit Agrawal , "broonie@kernel.org" , Steven Rostedt , Ingo Molnar Subject: Re: [RFC PATCH v6 1/9] tracing: Add array printing helpers Message-ID: <20141208143954.GB3902@e103592.cambridge.arm.com> References: <1417806260-9264-1-git-send-email-javi.merino@arm.com> <1417806260-9264-2-git-send-email-javi.merino@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1417806260-9264-2-git-send-email-javi.merino@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 05, 2014 at 07:04:12PM +0000, Javi Merino wrote: > From: Dave Martin > > If a trace event contains an array, there is currently no standard > way to format this for text output. Drivers are currently hacking > around this by a) local hacks that use the trace_seq functionailty > directly, or b) just not printing that information. For fixed size > arrays, formatting of the elements can be open-coded, but this gets > cumbersome for arrays of non-trivial size. > > These approaches result in non-standard content of the event format > description delivered to userspace, so userland tools needs to be > taught to understand and parse each array printing method > individually. > > This patch implements common __print__array() helpers that > tracepoint implementations can use instead of reinventing them. A > simple C-style syntax is used to delimit the array and its elements > {like,this}. > > So that the helpers can be used with large static arrays as well as > dynamic arrays, they take a pointer and element count: they can be > used with __get_dynamic_array() for use with dynamic arrays. > > Cc: Steven Rostedt > Cc: Ingo Molnar > Signed-off-by: Dave Martin > --- > include/linux/ftrace_event.h | 9 ++++++++ > include/trace/ftrace.h | 17 +++++++++++++++ > kernel/trace/trace_output.c | 51 ++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 77 insertions(+) > > diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h > index 28672e87e910..415afc53fa51 100644 > --- a/include/linux/ftrace_event.h > +++ b/include/linux/ftrace_event.h > @@ -44,6 +44,15 @@ const char *ftrace_print_bitmask_seq(struct trace_seq *p, void *bitmask_ptr, > const char *ftrace_print_hex_seq(struct trace_seq *p, > const unsigned char *buf, int len); > > +const char *ftrace_print_u8_array_seq(struct trace_seq *p, > + const u8 *buf, int count); > +const char *ftrace_print_u16_array_seq(struct trace_seq *p, > + const u16 *buf, int count); > +const char *ftrace_print_u32_array_seq(struct trace_seq *p, > + const u32 *buf, int count); > +const char *ftrace_print_u64_array_seq(struct trace_seq *p, > + const u64 *buf, int count); > + > struct trace_iterator; > struct trace_event; > > diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h > index 26b4f2e13275..15bc5d417aea 100644 > --- a/include/trace/ftrace.h > +++ b/include/trace/ftrace.h > @@ -263,6 +263,19 @@ > #undef __print_hex > #define __print_hex(buf, buf_len) ftrace_print_hex_seq(p, buf, buf_len) > > +#undef __print_u8_array > +#define __print_u8_array(array, count) \ > + ftrace_print_u8_array_seq(p, array, count) > +#undef __print_u16_array > +#define __print_u16_array(array, count) \ > + ftrace_print_u16_array_seq(p, array, count) > +#undef __print_u32_array > +#define __print_u32_array(array, count) \ > + ftrace_print_u32_array_seq(p, array, count) > +#undef __print_u64_array > +#define __print_u64_array(array, count) \ > + ftrace_print_u64_array_seq(p, array, count) > + > #undef DECLARE_EVENT_CLASS > #define DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print) \ > static notrace enum print_line_t \ > @@ -676,6 +689,10 @@ static inline void ftrace_test_probe_##call(void) \ > #undef __get_dynamic_array_len > #undef __get_str > #undef __get_bitmask > +#undef __print_u8_array > +#undef __print_u16_array > +#undef __print_u32_array > +#undef __print_u64_array > > #undef TP_printk > #define TP_printk(fmt, args...) "\"" fmt "\", " __stringify(args) > diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c > index c6977d5a9b12..4a6ee61f30b3 100644 > --- a/kernel/trace/trace_output.c > +++ b/kernel/trace/trace_output.c > @@ -186,6 +186,57 @@ ftrace_print_hex_seq(struct trace_seq *p, const unsigned char *buf, int buf_len) > } > EXPORT_SYMBOL(ftrace_print_hex_seq); > > +static const char * > +ftrace_print_array_seq(struct trace_seq *p, const void *buf, int buf_len, > + bool (*iterator)(struct trace_seq *p, const char *prefix, > + const void **buf, int *buf_len)) > +{ > + const char *ret = trace_seq_buffer_ptr(p); > + const char *prefix = ""; > + > + trace_seq_putc(p, '{'); > + > + while (iterator(p, prefix, &buf, &buf_len)) > + prefix = ","; Makes sense. > + > + trace_seq_putc(p, '}'); > + trace_seq_putc(p, 0); > + > + return ret; > +} > + > +#define DEFINE_PRINT_ARRAY(type, printk_type, format) \ > +static bool \ > +ftrace_print_array_iterator_##type(struct trace_seq *p, const char *prefix, \ > + const void **buf, int *buf_len) \ > +{ \ > + const type *__src = *buf; \ > + \ > + if (*buf_len < sizeof(*__src)) \ > + return false; \ > + \ > + trace_seq_printf(p, "%s" format, prefix, (printk_type)*__src++); \ > + \ > + *buf = __src; \ > + *buf_len -= sizeof(*__src); \ > + \ > + return true; \ > +} \ > + \ > +const char *ftrace_print_##type##_array_seq( \ > + struct trace_seq *p, const type *buf, int count) \ > +{ \ > + return ftrace_print_array_seq(p, buf, (count) * sizeof(type), \ > + ftrace_print_array_iterator_##type); \ > +} \ > + \ > +EXPORT_SYMBOL(ftrace_print_##type##_array_seq) > + > +DEFINE_PRINT_ARRAY(u8, unsigned int, "0x%x"); > +DEFINE_PRINT_ARRAY(u16, unsigned int, "0x%x"); > +DEFINE_PRINT_ARRAY(u32, unsigned int, "0x%x"); > +DEFINE_PRINT_ARRAY(u64, unsigned long long, "0x%llx"); (Responding to Steven's original comment on the choice of types here:) Steven Rostedt wrote: > > +DEFINE_PRINT_ARRAY(u8, unsigned int, "0x%x") > > Why not "unsigned char"? > > > +DEFINE_PRINT_ARRAY(u16, unsigned int, "0x%x") > > Why not "unsigned short"? [...] The original reason was to work around inconsistent definitions of u32 (unsigned int versus unsigned long) on different arches, so there was no way to write the format string that wouldn't trigger GCC warnings on some architectures. The kernel doesn't seem to provide the nasty C99 PRIxNN macros for now. Now that all arches seem to use asm-generic to define the u32 type, it looks like everyone uses the same definition, so this is probably not needed any more. I suggest we remove the printk_type argument completely and just use the underlying uNN type -- but build-testing on a mix of few 32-bit and 64-bit arches would be recommended, just to be on the safe side. Is there already precedent for this? It seems likely, but I haven't searched thoroughly. Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/