On Wed, 13 Dec 2023 10:09:50 +0200 Alexander Kapshuk <alexander.kapshuk@xxxxxxxxx> wrote: > The REs used in the sed commands below may be simplified as shown if desired. > > On Wed, Dec 13, 2023 at 2:22 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > From: "Steven Rostedt (Google)" <rostedt@xxxxxxxxxxx> > > > > Add a test that writes longs strings, some over the size of the sub buffer > > and make sure that the entire content is there. > > > > Signed-off-by: Steven Rostedt (Google) <rostedt@xxxxxxxxxxx> > > --- > > Changes since v2: https://lore.kernel.org/linux-trace-kernel/20231212151632.25c9b67d@xxxxxxxxxxxxxxxxxx > > > > - Realized with the upcoming change of the dynamic subbuffer sizes, that > > this test will fail if the subbuffer is bigger than what the trace_seq > > can hold. Now the trace_marker does not always utilize the full subbuffer > > but the size of the trace_seq instead. As that size isn't available to > > user space, we can only just make sure all content is there. > > > > .../ftrace/test.d/00basic/trace_marker.tc | 82 +++++++++++++++++++ > > 1 file changed, 82 insertions(+) > > create mode 100755 tools/testing/selftests/ftrace/test.d/00basic/trace_marker.tc > > > > diff --git a/tools/testing/selftests/ftrace/test.d/00basic/trace_marker.tc b/tools/testing/selftests/ftrace/test.d/00basic/trace_marker.tc > > new file mode 100755 > > index 000000000000..b24aff5807df > > --- /dev/null > > +++ b/tools/testing/selftests/ftrace/test.d/00basic/trace_marker.tc > > @@ -0,0 +1,82 @@ > > +#!/bin/sh > > +# SPDX-License-Identifier: GPL-2.0 > > +# description: Basic tests on writing to trace_marker > > +# requires: trace_marker > > +# flags: instance > > + > > +get_buffer_data_size() { > > + sed -ne 's/^.*data.*size:\([0-9][0-9]*\).*/\1/p' events/header_page > sed -n 's!.*data.*size:\([^;]*\).*!\1!p' events/header_page Not sure the above change can be considered simpler, but it also loses out showing what exactly is being done. With the original, I have: sed -ne 's/^.*data.*size:\([0-9][0-9]*\).*/\1/p' events/header_page Which is obvious that I'm grabbing a number for the size field. sed -n 's!.*data.*size:\([^;]*\).*!\1!p' events/header_page Shows that I'm grabbing something after size. > > +} > > + > > +get_buffer_data_offset() { > > + sed -ne 's/^.*data.*offset:\([0-9][0-9]*\).*/\1/p' events/header_page > sed -n 's!.*data.*offset:\([^;]*\).*!\1!p' events/header_page Same here. > > +} > > + > > +get_event_header_size() { > > + type_len=`sed -ne 's/^.*type_len.*:[^0-9]*\([0-9][0-9]*\).*/\1/p' events/header_event` > type_len=`sed -n '/type_len.*bits/s![^0-9]*!!gp' > events/header_event` Honestly, the above may be "simplier" but I can't make out what exactly that line is doing without going back and looking at the text that's in the format field. > > > + time_len=`sed -ne 's/^.*time_delta.*:[^0-9]*\([0-9][0-9]*\).*/\1/p' events/header_event` > time_len=`sed -n '/time_delta/s![^0-9]*!!gp' events/header_event` > > > + array_len=`sed -ne 's/^.*array.*:[^0-9]*\([0-9][0-9]*\).*/\1/p' events/header_event` > array_len=`sed -n '/array/s![^0-9]*!!gp' events/header_event` > > > + total_bits=$((type_len+time_len+array_len)) > > + total_bits=$((total_bits+7)) > > + echo $((total_bits/8)) > > +} > > + > > +get_print_event_buf_offset() { > > + sed -ne 's/^.*buf.*offset:\([0-9][0-9]*\).*/\1/p' events/ftrace/print/format > sed -n 's!.*buf.*offset:\([^;]*\).*!\1!p' events/ftrace/print/format > > +} > > + Yeah, thanks for the suggestions, but I rather have it be more readable than "simplified". I write perl code the same way. I do not write it like any perl developer would, because I write it like C code. I want my code to be easily understandable. RE can become extremely obfuscated. So, even though my REs are not the simplest, they tend to be rather easy to understand what they are doing, and why. Cheers, -- Steve
