Re: linux-next: build warnings after merge of the ftrace tree
From: Bagas Sanjaya
Date: Tue Jan 31 2023 - 03:25:12 EST
On 1/31/23 01:51, Steven Rostedt wrote:
> krobot saw this too. I'm thinking this can fix it:
>
> -- Steve
>
> diff --git a/Documentation/trace/histogram.rst b/Documentation/trace/histogram.rst
> index 5c391328b9bb..026eef03afe0 100644
> --- a/Documentation/trace/histogram.rst
> +++ b/Documentation/trace/histogram.rst
> @@ -1864,7 +1864,7 @@ A histogram can now be defined for the new synthetic event::
> The above shows the latency "lat" in a power of 2 grouping.
>
> Like any other event, once a histogram is enabled for the event, the
> -output can be displayed by reading the event's 'hist' file.
> +output can be displayed by reading the event's 'hist' file::
>
> # cat /sys/kernel/debug/tracing/events/synthetic/wakeup_latency/hist
>
> @@ -1911,7 +1911,7 @@ output can be displayed by reading the event's 'hist' file.
>
>
> The latency values can also be grouped linearly by a given size with
> -the ".buckets" modifier and specify a size (in this case groups of 10).
> +the ".buckets" modifier and specify a size (in this case groups of 10)::
>
> # echo 'hist:keys=pid,prio,lat.buckets=10:sort=lat' >> \
> /sys/kernel/debug/tracing/events/synthetic/wakeup_latency/trigger
> @@ -1945,7 +1945,7 @@ the ".buckets" modifier and specify a size (in this case groups of 10).
>
> To save stacktraces, create a synthetic event with a field of type "unsigned long[]"
> or even just "long[]". For example, to see how long a task is blocked in an
> -uninterruptible state:
> +uninterruptible state::
>
> # cd /sys/kernel/tracing
> # echo 's:block_lat pid_t pid; u64 delta; unsigned long[] stack;' > dynamic_events
> @@ -1990,7 +1990,7 @@ uninterruptible state:
> => kthread+0xe9/0x110
> => ret_from_fork+0x2c/0x50
>
> -A synthetic event that has a stacktrace field may use it as a key in histogram:
> +A synthetic event that has a stacktrace field may use it as a key in histogram::
>
> # echo 'hist:delta.buckets=100,stack.stacktrace:sort=delta' > events/synthetic/block_lat/trigger
> # cat events/synthetic/block_lat/hist
> @@ -2183,7 +2183,7 @@ The following commonly-used handler.action pairs are available:
> wakeup_new_test($testpid) if comm=="cyclictest"' >> \
> /sys/kernel/debug/tracing/events/sched/sched_wakeup_new/trigger
>
> - Or, equivalently, using the 'trace' keyword syntax:
> + Or, equivalently, using the 'trace' keyword syntax::
>
> # echo 'hist:keys=$testpid:testpid=pid:onmatch(sched.sched_wakeup_new).\
> trace(wakeup_new_test,$testpid) if comm=="cyclictest"' >> \
> @@ -2320,7 +2320,7 @@ The following commonly-used handler.action pairs are available:
> resulting latency, stored in wakeup_lat, exceeds the current
> maximum latency, a snapshot is taken. As part of the setup, all
> the scheduler events are also enabled, which are the events that
> - will show up in the snapshot when it is taken at some point:
> + will show up in the snapshot when it is taken at some point::
>
> # echo 1 > /sys/kernel/debug/tracing/events/sched/enable
>
> @@ -2339,7 +2339,7 @@ The following commonly-used handler.action pairs are available:
> following the rest of the fields.
>
> If a snapshot was taken, there is also a message indicating that,
> - along with the value and event that triggered the global maximum:
> + along with the value and event that triggered the global maximum::
>
> # cat /sys/kernel/debug/tracing/events/sched/sched_switch/hist
> { next_pid: 2101 } hitcount: 200
> @@ -2439,7 +2439,7 @@ The following commonly-used handler.action pairs are available:
> $cwnd variable. If the value has changed, a snapshot is taken.
> As part of the setup, all the scheduler and tcp events are also
> enabled, which are the events that will show up in the snapshot
> - when it is taken at some point:
> + when it is taken at some point::
>
> # echo 1 > /sys/kernel/debug/tracing/events/sched/enable
> # echo 1 > /sys/kernel/debug/tracing/events/tcp/enable
Hi Steve,
I had already sent the fix, which also include required indentation changes
to make code blocks alignment nicer at [1].
Thanks.
[1]: https://lore.kernel.org/linux-doc/20230129031402.47420-1-bagasdotme@xxxxxxxxx/
--
An old man doll... just what I always wanted! - Clara