linux-next: manual merge of the ftrace tree with the jc_docs tree

linux-next: manual merge of the ftrace tree with the jc_docs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 8739 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  Documentation/trace/histogram.rst

between commit:

  2abfcd293b79 ("docs: ftrace: always use canonical ftrace path")

from the jc_docs tree and commit:

  a2ff84a5d1e6 ("tracing/histogram: Wrap remaining shell snippets in code blocks")

from the ftrace tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/trace/histogram.rst
index 7b7e4893b8f6,8e95295e39b6..000000000000
--- a/Documentation/trace/histogram.rst
+++ b/Documentation/trace/histogram.rst
@@@ -1861,9 -1864,9 +1864,9 @@@ A histogram can now be defined for the 
  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
 +  # cat /sys/kernel/tracing/events/synthetic/wakeup_latency/hist
  
    # event histogram
    #
@@@ -1908,10 -1911,10 +1911,10 @@@
  
  
  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
 +        /sys/kernel/tracing/events/synthetic/wakeup_latency/trigger
  
    # event histogram
    #
@@@ -2052,13 -2182,13 +2182,13 @@@ The following commonly-used handler.act
  
        # echo 'hist:keys=$testpid:testpid=pid:onmatch(sched.sched_wakeup_new).\
                wakeup_new_test($testpid) if comm=="cyclictest"' >> \
 -              /sys/kernel/debug/tracing/events/sched/sched_wakeup_new/trigger
 +              /sys/kernel/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"' >> \
-             /sys/kernel/tracing/events/sched/sched_wakeup_new/trigger
+       # echo 'hist:keys=$testpid:testpid=pid:onmatch(sched.sched_wakeup_new).\
+               trace(wakeup_new_test,$testpid) if comm=="cyclictest"' >> \
 -              /sys/kernel/debug/tracing/events/sched/sched_wakeup_new/trigger
++              /sys/kernel/tracing/events/sched/sched_wakeup_new/trigger
  
      Creating and displaying a histogram based on those events is now
      just a matter of using the fields and new synthetic event in the
@@@ -2191,48 -2321,48 +2321,48 @@@
      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/tracing/events/sched/enable
 -      # echo 1 > /sys/kernel/debug/tracing/events/sched/enable
++      # echo 1 > /sys/kernel/tracing/events/sched/enable
  
-     # echo 'hist:keys=pid:ts0=common_timestamp.usecs \
-             if comm=="cyclictest"' >> \
-             /sys/kernel/tracing/events/sched/sched_waking/trigger
+       # echo 'hist:keys=pid:ts0=common_timestamp.usecs \
+               if comm=="cyclictest"' >> \
 -              /sys/kernel/debug/tracing/events/sched/sched_waking/trigger
++              /sys/kernel/tracing/events/sched/sched_waking/trigger
  
-     # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0: \
-             onmax($wakeup_lat).save(next_prio,next_comm,prev_pid,prev_prio, \
- 	    prev_comm):onmax($wakeup_lat).snapshot() \
- 	    if next_comm=="cyclictest"' >> \
- 	    /sys/kernel/tracing/events/sched/sched_switch/trigger
+       # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0: \
+               onmax($wakeup_lat).save(next_prio,next_comm,prev_pid,prev_prio, \
+ 	      prev_comm):onmax($wakeup_lat).snapshot() \
+ 	      if next_comm=="cyclictest"' >> \
 -	      /sys/kernel/debug/tracing/events/sched/sched_switch/trigger
++	      /sys/kernel/tracing/events/sched/sched_switch/trigger
  
      When the histogram is displayed, for each bucket the max value
      and the saved values corresponding to the max are displayed
      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/tracing/events/sched/sched_switch/hist
-       { next_pid:       2101 } hitcount:        200
- 	max:         52  next_prio:        120  next_comm: cyclictest \
-         prev_pid:          0  prev_prio:        120  prev_comm: swapper/6
 -      # cat /sys/kernel/debug/tracing/events/sched/sched_switch/hist
++      # cat /sys/kernel/tracing/events/sched/sched_switch/hist
+         { next_pid:       2101 } hitcount:        200
+ 	  max:         52  next_prio:        120  next_comm: cyclictest \
+           prev_pid:          0  prev_prio:        120  prev_comm: swapper/6
  
-       { next_pid:       2103 } hitcount:       1326
- 	max:        572  next_prio:         19  next_comm: cyclictest \
-         prev_pid:          0  prev_prio:        120  prev_comm: swapper/1
+         { next_pid:       2103 } hitcount:       1326
+ 	  max:        572  next_prio:         19  next_comm: cyclictest \
+           prev_pid:          0  prev_prio:        120  prev_comm: swapper/1
  
-       { next_pid:       2102 } hitcount:       1982 \
- 	max:         74  next_prio:         19  next_comm: cyclictest \
-         prev_pid:          0  prev_prio:        120  prev_comm: swapper/5
+         { next_pid:       2102 } hitcount:       1982 \
+ 	  max:         74  next_prio:         19  next_comm: cyclictest \
+           prev_pid:          0  prev_prio:        120  prev_comm: swapper/5
  
-     Snapshot taken (see tracing/snapshot).  Details:
- 	triggering value { onmax($wakeup_lat) }:        572	\
- 	triggered by event with key: { next_pid:       2103 }
+       Snapshot taken (see tracing/snapshot).  Details:
+ 	  triggering value { onmax($wakeup_lat) }:        572	\
+ 	  triggered by event with key: { next_pid:       2103 }
  
-     Totals:
-         Hits: 3508
-         Entries: 3
-         Dropped: 0
+       Totals:
+           Hits: 3508
+           Entries: 3
+           Dropped: 0
  
      In the above case, the event that triggered the global maximum has
      the key with next_pid == 2103.  If you look at the bucket that has
@@@ -2310,15 -2440,15 +2440,15 @@@
      $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/tracing/events/sched/enable
-     # echo 1 > /sys/kernel/tracing/events/tcp/enable
 -      # echo 1 > /sys/kernel/debug/tracing/events/sched/enable
 -      # echo 1 > /sys/kernel/debug/tracing/events/tcp/enable
++      # echo 1 > /sys/kernel/tracing/events/sched/enable
++      # echo 1 > /sys/kernel/tracing/events/tcp/enable
  
-     # echo 'hist:keys=dport:cwnd=snd_cwnd: \
-             onchange($cwnd).save(snd_wnd,srtt,rcv_wnd): \
- 	    onchange($cwnd).snapshot()' >> \
- 	    /sys/kernel/tracing/events/tcp/tcp_probe/trigger
+       # echo 'hist:keys=dport:cwnd=snd_cwnd: \
+               onchange($cwnd).save(snd_wnd,srtt,rcv_wnd): \
+ 	      onchange($cwnd).snapshot()' >> \
 -	      /sys/kernel/debug/tracing/events/tcp/tcp_probe/trigger
++	      /sys/kernel/tracing/events/tcp/tcp_probe/trigger
  
      When the histogram is displayed, for each bucket the tracked value
      and the saved values corresponding to that value are displayed

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the ftrace tree with the jc_docs tree

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 8449 bytes --]

On Wed, Feb 15, 2023 at 12:16:38PM +1100, Stephen Rothwell wrote:
> diff --cc Documentation/trace/histogram.rst
> index 7b7e4893b8f6,8e95295e39b6..000000000000
> --- a/Documentation/trace/histogram.rst
> +++ b/Documentation/trace/histogram.rst
> @@@ -1861,9 -1864,9 +1864,9 @@@ A histogram can now be defined for the 
>   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
>  +  # cat /sys/kernel/tracing/events/synthetic/wakeup_latency/hist
>   
>     # event histogram
>     #
> @@@ -1908,10 -1911,10 +1911,10 @@@
>   
>   
>   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
>  +        /sys/kernel/tracing/events/synthetic/wakeup_latency/trigger
>   
>     # event histogram
>     #
> @@@ -2052,13 -2182,13 +2182,13 @@@ The following commonly-used handler.act
>   
>         # echo 'hist:keys=$testpid:testpid=pid:onmatch(sched.sched_wakeup_new).\
>                 wakeup_new_test($testpid) if comm=="cyclictest"' >> \
>  -              /sys/kernel/debug/tracing/events/sched/sched_wakeup_new/trigger
>  +              /sys/kernel/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"' >> \
> -             /sys/kernel/tracing/events/sched/sched_wakeup_new/trigger
> +       # echo 'hist:keys=$testpid:testpid=pid:onmatch(sched.sched_wakeup_new).\
> +               trace(wakeup_new_test,$testpid) if comm=="cyclictest"' >> \
>  -              /sys/kernel/debug/tracing/events/sched/sched_wakeup_new/trigger
> ++              /sys/kernel/tracing/events/sched/sched_wakeup_new/trigger
>   
>       Creating and displaying a histogram based on those events is now
>       just a matter of using the fields and new synthetic event in the
> @@@ -2191,48 -2321,48 +2321,48 @@@
>       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/tracing/events/sched/enable
>  -      # echo 1 > /sys/kernel/debug/tracing/events/sched/enable
> ++      # echo 1 > /sys/kernel/tracing/events/sched/enable
>   
> -     # echo 'hist:keys=pid:ts0=common_timestamp.usecs \
> -             if comm=="cyclictest"' >> \
> -             /sys/kernel/tracing/events/sched/sched_waking/trigger
> +       # echo 'hist:keys=pid:ts0=common_timestamp.usecs \
> +               if comm=="cyclictest"' >> \
>  -              /sys/kernel/debug/tracing/events/sched/sched_waking/trigger
> ++              /sys/kernel/tracing/events/sched/sched_waking/trigger
>   
> -     # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0: \
> -             onmax($wakeup_lat).save(next_prio,next_comm,prev_pid,prev_prio, \
> - 	    prev_comm):onmax($wakeup_lat).snapshot() \
> - 	    if next_comm=="cyclictest"' >> \
> - 	    /sys/kernel/tracing/events/sched/sched_switch/trigger
> +       # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0: \
> +               onmax($wakeup_lat).save(next_prio,next_comm,prev_pid,prev_prio, \
> + 	      prev_comm):onmax($wakeup_lat).snapshot() \
> + 	      if next_comm=="cyclictest"' >> \
>  -	      /sys/kernel/debug/tracing/events/sched/sched_switch/trigger
> ++	      /sys/kernel/tracing/events/sched/sched_switch/trigger
>   
>       When the histogram is displayed, for each bucket the max value
>       and the saved values corresponding to the max are displayed
>       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/tracing/events/sched/sched_switch/hist
> -       { next_pid:       2101 } hitcount:        200
> - 	max:         52  next_prio:        120  next_comm: cyclictest \
> -         prev_pid:          0  prev_prio:        120  prev_comm: swapper/6
>  -      # cat /sys/kernel/debug/tracing/events/sched/sched_switch/hist
> ++      # cat /sys/kernel/tracing/events/sched/sched_switch/hist
> +         { next_pid:       2101 } hitcount:        200
> + 	  max:         52  next_prio:        120  next_comm: cyclictest \
> +           prev_pid:          0  prev_prio:        120  prev_comm: swapper/6
>   
> -       { next_pid:       2103 } hitcount:       1326
> - 	max:        572  next_prio:         19  next_comm: cyclictest \
> -         prev_pid:          0  prev_prio:        120  prev_comm: swapper/1
> +         { next_pid:       2103 } hitcount:       1326
> + 	  max:        572  next_prio:         19  next_comm: cyclictest \
> +           prev_pid:          0  prev_prio:        120  prev_comm: swapper/1
>   
> -       { next_pid:       2102 } hitcount:       1982 \
> - 	max:         74  next_prio:         19  next_comm: cyclictest \
> -         prev_pid:          0  prev_prio:        120  prev_comm: swapper/5
> +         { next_pid:       2102 } hitcount:       1982 \
> + 	  max:         74  next_prio:         19  next_comm: cyclictest \
> +           prev_pid:          0  prev_prio:        120  prev_comm: swapper/5
>   
> -     Snapshot taken (see tracing/snapshot).  Details:
> - 	triggering value { onmax($wakeup_lat) }:        572	\
> - 	triggered by event with key: { next_pid:       2103 }
> +       Snapshot taken (see tracing/snapshot).  Details:
> + 	  triggering value { onmax($wakeup_lat) }:        572	\
> + 	  triggered by event with key: { next_pid:       2103 }
>   
> -     Totals:
> -         Hits: 3508
> -         Entries: 3
> -         Dropped: 0
> +       Totals:
> +           Hits: 3508
> +           Entries: 3
> +           Dropped: 0
>   
>       In the above case, the event that triggered the global maximum has
>       the key with next_pid == 2103.  If you look at the bucket that has
> @@@ -2310,15 -2440,15 +2440,15 @@@
>       $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/tracing/events/sched/enable
> -     # echo 1 > /sys/kernel/tracing/events/tcp/enable
>  -      # echo 1 > /sys/kernel/debug/tracing/events/sched/enable
>  -      # echo 1 > /sys/kernel/debug/tracing/events/tcp/enable
> ++      # echo 1 > /sys/kernel/tracing/events/sched/enable
> ++      # echo 1 > /sys/kernel/tracing/events/tcp/enable
>   
> -     # echo 'hist:keys=dport:cwnd=snd_cwnd: \
> -             onchange($cwnd).save(snd_wnd,srtt,rcv_wnd): \
> - 	    onchange($cwnd).snapshot()' >> \
> - 	    /sys/kernel/tracing/events/tcp/tcp_probe/trigger
> +       # echo 'hist:keys=dport:cwnd=snd_cwnd: \
> +               onchange($cwnd).save(snd_wnd,srtt,rcv_wnd): \
> + 	      onchange($cwnd).snapshot()' >> \
>  -	      /sys/kernel/debug/tracing/events/tcp/tcp_probe/trigger
> ++	      /sys/kernel/tracing/events/tcp/tcp_probe/trigger
>   
>       When the histogram is displayed, for each bucket the tracked value
>       and the saved values corresponding to that value are displayed

The resolution LGTM, thanks!

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

linux-next: manual merge of the ftrace tree with the jc_docs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  Documentation/tools/rtla/common_options.txt

between commits:

  96b546c241b1 ("Documentation/rtla: rename common_xxx.rst files to common_xxx.txt")
  198fcc7cb832 ("Documentation/rtla: Mention default priority")

from the jc_docs tree and commit:

  90241d14a726 ("rtla: Fix -C/--cgroup interface")

from the ftrace tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/tools/rtla/common_options.txt
index 1c4f3e663cf5,edc8e850f5d0..000000000000
--- a/Documentation/tools/rtla/common_options.txt
+++ b/Documentation/tools/rtla/common_options.txt
@@@ -46,9 -42,7 +46,9 @@@
          - *f:prio* - use SCHED_FIFO with *prio*;
          - *d:runtime[us|ms|s]:period[us|ms|s]* - use SCHED_DEADLINE with *runtime* and *period* in nanoseconds.
  
 +        If not set, tracer threads keep their default priority. For rtla user threads, it is set to SCHED_FIFO with priority 95. For kernel threads, see *osnoise* and *timerlat* tracer documentation for the running kernel version.
 +
- **-C**, **--cgroup**\[*=cgroup*]
+ **-C**, **--cgroup** \[*cgroup*]
  
          Set a *cgroup* to the tracer's threads. If the **-C** option is passed without arguments, the tracer's thread will inherit **rtla**'s *cgroup*. Otherwise, the threads will be placed on the *cgroup* passed to the option.
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the ftrace tree with the jc_docs tree

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

On Fri, Nov 21, 2025 at 12:35:09PM +1100, Stephen Rothwell wrote:
> diff --cc Documentation/tools/rtla/common_options.txt
> index 1c4f3e663cf5,edc8e850f5d0..000000000000
> --- a/Documentation/tools/rtla/common_options.txt
> +++ b/Documentation/tools/rtla/common_options.txt
> @@@ -46,9 -42,7 +46,9 @@@
>           - *f:prio* - use SCHED_FIFO with *prio*;
>           - *d:runtime[us|ms|s]:period[us|ms|s]* - use SCHED_DEADLINE with *runtime* and *period* in nanoseconds.
>   
>  +        If not set, tracer threads keep their default priority. For rtla user threads, it is set to SCHED_FIFO with priority 95. For kernel threads, see *osnoise* and *timerlat* tracer documentation for the running kernel version.
>  +
> - **-C**, **--cgroup**\[*=cgroup*]
> + **-C**, **--cgroup** \[*cgroup*]
>   
>           Set a *cgroup* to the tracer's threads. If the **-C** option is passed without arguments, the tracer's thread will inherit **rtla**'s *cgroup*. Otherwise, the threads will be placed on the *cgroup* passed to the option.
>   

The resolution LGTM, thanks!

-- 
An old man doll... just what I always wanted! - Clara

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: linux-next: manual merge of the ftrace tree with the jc_docs tree

[Gopi Krishna Menon]

On Fri, Nov 21, 2025 at 12:35:09PM +1100, Stephen Rothwell wrote:

> Hi all,
> 
> Today's linux-next merge of the ftrace tree got a conflict in:
> 
>   Documentation/tools/rtla/common_options.txt
> 
> between commits:
> 
>   96b546c241b1 ("Documentation/rtla: rename common_xxx.rst files to common_xxx.txt")
>   198fcc7cb832 ("Documentation/rtla: Mention default priority")
> 
> from the jc_docs tree and commit:
> 
>   90241d14a726 ("rtla: Fix -C/--cgroup interface")
> 
> from the ftrace tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc Documentation/tools/rtla/common_options.txt
> index 1c4f3e663cf5,edc8e850f5d0..000000000000
> --- a/Documentation/tools/rtla/common_options.txt
> +++ b/Documentation/tools/rtla/common_options.txt
> @@@ -46,9 -42,7 +46,9 @@@
>           - *f:prio* - use SCHED_FIFO with *prio*;
>           - *d:runtime[us|ms|s]:period[us|ms|s]* - use SCHED_DEADLINE with *runtime* and *period* in nanoseconds.
>   
>  +        If not set, tracer threads keep their default priority. For rtla user threads, it is set to SCHED_FIFO with priority 95. For kernel threads, see *osnoise* and *timerlat* tracer documentation for the running kernel version.
>  +
> - **-C**, **--cgroup**\[*=cgroup*]
> + **-C**, **--cgroup** \[*cgroup*]
>   
>           Set a *cgroup* to the tracer's threads. If the **-C** option is passed without arguments, the tracer's thread will inherit **rtla**'s *cgroup*. Otherwise, the threads will be placed on the *cgroup* passed to the option.
>   


LGTM, thanks
Gopi Krishna Menon

linux-next: manual merge of the ftrace tree with the jc_docs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  Documentation/trace/kprobetrace.rst

between commit:

  5d18c23c763d ("Documentation: kprobetrace: Split paragraphs")

from the jc_docs tree and commit:

  ce9c752ee1e7 ("tracing/probe: add a char type to show the character value of traced arguments")

from the ftrace tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/trace/kprobetrace.rst
index 0d103074d3d2,ef223b8ad6d5..000000000000
--- a/Documentation/trace/kprobetrace.rst
+++ b/Documentation/trace/kprobetrace.rst
@@@ -81,7 -80,7 +81,9 @@@ E.g. 'x16[4]' means an array of x16 (2-
  Note that the array can be applied to memory type fetchargs, you can not
  apply it to registers/stack-entries etc. (for example, '$stack1:x8[8]' is
  wrong, but '+8($stack):x8[8]' is OK.)
 +
+ Char type can be used to show the character value of traced arguments.
++
  String type is a special type, which fetches a "null-terminated" string from
  kernel space. This means it will fail and store NULL if the string container
  has been paged out. "ustring" type is an alternative of string for user-space.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the ftrace tree with the jc_docs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]

Hi all,

Today's linux-next merge of the ftrace tree got a conflict in:

  MAINTAINERS

between commit:

  0c3b533cfdd5 ("MAINTAINERS: add entry for traditional Chinese documentation")

from the jc_docs tree and commit:

  db396be6ddc4 ("MAINTAINERS: Add an entry for os noise/latency")

from the ftrace tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc MAINTAINERS
index 34cbc59bbea0,4268644cf86a..000000000000
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -18921,14 -18798,20 +18921,28 @@@ F:	arch/x86/mm/testmmiotrace.
  F:	include/linux/mmiotrace.h
  F:	kernel/trace/trace_mmiotrace.c
  
+ TRACING OS NOISE / LATENCY TRACERS
+ M:	Steven Rostedt <rostedt@goodmis.org>
+ M:	Daniel Bristot de Oliveira <bristot@kernel.org>
+ S:	Maintained
+ F:	kernel/trace/trace_osnoise.c
+ F:	include/trace/events/osnoise.h
+ F:	kernel/trace/trace_hwlat.c
+ F:	kernel/trace/trace_irqsoff.c
+ F:	kernel/trace/trace_sched_wakeup.c
+ F:	Documentation/trace/osnoise-tracer.rst
+ F:	Documentation/trace/timerlat-tracer.rst
+ F:	Documentation/trace/hwlat_detector.rst
+ F:	arch/*/kernel/trace.c
+ 
 +TRADITIONAL CHINESE DOCUMENTATION
 +M:	Hu Haowen <src.res@email.cn>
 +L:	linux-doc-tw-discuss@lists.sourceforge.net
 +S:	Maintained
 +W:	https://github.com/srcres258/linux-doc
 +T:	git git://github.com/srcres258/linux-doc.git doc-zh-tw
 +F:	Documentation/translations/zh_TW/
 +
  TRIVIAL PATCHES
  M:	Jiri Kosina <trivial@kernel.org>
  S:	Maintained

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the ftrace tree with the jc_docs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2403 bytes --]

Hi Steven,

Today's linux-next merge of the ftrace tree got a conflict in:

  Documentation/trace/ftrace.txt
  (converted to Documentation/trace/ftrace.rst)

between commit:

  1f198e22bc3a ("trace doc: convert trace/ftrace.txt to rst format")

from the jc_docs tree and commit:

  2c1ea60b195d ("tracing: Add timestamp_mode trace file")

from the ftrace tree.

I fixed it up (I deleted the file and added the merge fix patch below -
which probably needs more work) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non
trivial conflicts should be mentioned to your upstream maintainer when
your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 21 Mar 2018 15:29:08 +1100
Subject: [PATCH] trace doc: merge fix for rst conversion of ftrace.txt

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 Documentation/trace/ftrace.rst | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index 55637926abdc..8aad686ff9a5 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -543,6 +543,30 @@ of ftrace. Here is a list of some of the key files:
 
 	See events.txt for more information.
 
+  timestamp_mode:
+
+	Certain tracers may change the timestamp mode used when
+	logging trace events into the event buffer.  Events with
+	different modes can coexist within a buffer but the mode in
+	effect when an event is logged determines which timestamp mode
+	is used for that event.  The default timestamp mode is
+	'delta'.
+
+	Usual timestamp modes for tracing:
+
+	  # cat timestamp_mode
+	  [delta] absolute
+
+	  The timestamp mode with the square brackets around it is the
+	  one in effect.
+
+	  delta: Default timestamp mode - timestamp is a delta against
+	         a per-buffer timestamp.
+
+	  absolute: The timestamp is a full timestamp, not a delta
+                 against some other value.  As such it takes up more
+                 space and is less efficient.
+
   hwlat_detector:
 
 	Directory for the Hardware Latency Detector.
-- 
2.16.1

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the ftrace tree with the jc_docs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

Hi all,

On Wed, 21 Mar 2018 15:31:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the ftrace tree got a conflict in:
> 
>   Documentation/trace/ftrace.txt
>   (converted to Documentation/trace/ftrace.rst)

There was another conflict involving

  Documentation/trace/events.{txt,rst}

Unfortunately, I accidentally deleted the report email before sending
it :-(

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the ftrace tree with the jc_docs tree

[Steven Rostedt]

On Wed, 21 Mar 2018 15:37:15 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Wed, 21 Mar 2018 15:31:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the ftrace tree got a conflict in:
> > 
> >   Documentation/trace/ftrace.txt
> >   (converted to Documentation/trace/ftrace.rst)  
> 
> There was another conflict involving
> 
>   Documentation/trace/events.{txt,rst}
> 
> Unfortunately, I accidentally deleted the report email before sending
> it :-(
> 

Ug yeah. All the histogram code was ripped out of the events.txt and
a new file was created called histogram.txt. I'm guessing that should
also be converted into an .rst file.

-- Steve

Re: linux-next: manual merge of the ftrace tree with the jc_docs tree

[Tom Zanussi]

On Wed, 2018-03-21 at 09:15 -0400, Steven Rostedt wrote:
> On Wed, 21 Mar 2018 15:37:15 +1100
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi all,
> > 
> > On Wed, 21 Mar 2018 15:31:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Today's linux-next merge of the ftrace tree got a conflict in:
> > > 
> > >   Documentation/trace/ftrace.txt
> > >   (converted to Documentation/trace/ftrace.rst)  
> > 
> > There was another conflict involving
> > 
> >   Documentation/trace/events.{txt,rst}
> > 
> > Unfortunately, I accidentally deleted the report email before sending
> > it :-(
> > 
> 
> Ug yeah. All the histogram code was ripped out of the events.txt and
> a new file was created called histogram.txt. I'm guessing that should
> also be converted into an .rst file.
> 

Yeah, linux-next has changes to Documentation/trace/* that converts
those files to .rst, which linux-trace/frace/core doesn't have.

I've rebased the inter-event patches to linux-next/next-20180320 to
reflect those changes, which affect 9 of the files in the patchset.  The
updated patchset is here:

https://github.com/tzanussi/linux-trace-inter-event.git tzanussi/next-20180320-inter-event-v10                                               
https://github.com/tzanussi/linux-trace-inter-event/tree/tzanussi/next-20180320-inter-event-v10

I can repost the whole thing as v10, or whatever makes sense here.

Thanks,

Tom

> -- Steve

Re: linux-next: manual merge of the ftrace tree with the jc_docs tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

Hi Tom,

On Wed, 21 Mar 2018 15:55:52 -0500 Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
>
> Yeah, linux-next has changes to Documentation/trace/* that converts
> those files to .rst, which linux-trace/frace/core doesn't have.
> 
> I've rebased the inter-event patches to linux-next/next-20180320 to
> reflect those changes, which affect 9 of the files in the patchset.  The
> updated patchset is here:
> 
> https://github.com/tzanussi/linux-trace-inter-event.git tzanussi/next-20180320-inter-event-v10                                               
> https://github.com/tzanussi/linux-trace-inter-event/tree/tzanussi/next-20180320-inter-event-v10
> 
> I can repost the whole thing as v10, or whatever makes sense here.

Thanks, I assume that they apply on top of the jc_docs tree as well
(git://git.lwn.net/linux.git#docs-next).  If so, then I can use them as
merge resolutions, or Steve can rebase his tree (minus your old
patches) on top of the (hopefully unchanging) jc_docs tree and then he
could apply your patches there.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the ftrace tree with the jc_docs tree

[Tom Zanussi]

Hi Stephen,

On Thu, 2018-03-22 at 09:21 +1100, Stephen Rothwell wrote:
> Hi Tom,
> 
> On Wed, 21 Mar 2018 15:55:52 -0500 Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> >
> > Yeah, linux-next has changes to Documentation/trace/* that converts
> > those files to .rst, which linux-trace/frace/core doesn't have.
> > 
> > I've rebased the inter-event patches to linux-next/next-20180320 to
> > reflect those changes, which affect 9 of the files in the patchset.  The
> > updated patchset is here:
> > 
> > https://github.com/tzanussi/linux-trace-inter-event.git tzanussi/next-20180320-inter-event-v10                                               
> > https://github.com/tzanussi/linux-trace-inter-event/tree/tzanussi/next-20180320-inter-event-v10
> > 
> > I can repost the whole thing as v10, or whatever makes sense here.
> 
> Thanks, I assume that they apply on top of the jc_docs tree as well
> (git://git.lwn.net/linux.git#docs-next).  If so, then I can use them as
> merge resolutions, or Steve can rebase his tree (minus your old
> patches) on top of the (hopefully unchanging) jc_docs tree and then he
> could apply your patches there.
> 

Yes, just checked and they do apply on top of the jc_docs branch
mentioned.

Thanks,

Tom 

Re: linux-next: manual merge of the ftrace tree with the jc_docs tree

[Steven Rostedt]

On Thu, 22 Mar 2018 09:21:08 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > I can repost the whole thing as v10, or whatever makes sense here.  
> 
> Thanks, I assume that they apply on top of the jc_docs tree as well
> (git://git.lwn.net/linux.git#docs-next).  If so, then I can use them as
> merge resolutions, or Steve can rebase his tree (minus your old
> patches) on top of the (hopefully unchanging) jc_docs tree and then he
> could apply your patches there.

Too late for a rebase. I've already run it through my tests and posted,
I don't rebase anything that goes to linux-next unless there's a really
good reason to do so. I don't think this is one.

I'll just make sure Linus knows about it and have a link to point to
the proper end results. He's stated he's fine with those kinds of
solutions. And since this is only a documentation conflict, we don't
need to worry about mistakes causing subtle behavior with the kernel.

-- Steve