<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/tools/build, branch v6.17</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.17</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.17'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2025-06-26T17:51:41Z</updated>
<entry>
<title>tools: Remove libcrypto dependency</title>
<updated>2025-06-26T17:51:41Z</updated>
<author>
<name>Yuzhuo Jing</name>
<email>yuzhuo@google.com</email>
</author>
<published>2025-06-25T20:23:11Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8e63fd1e00f59eab01ab43eb094abc380f8d0c28'/>
<id>urn:sha1:8e63fd1e00f59eab01ab43eb094abc380f8d0c28</id>
<content type='text'>
Remove all occurrence of libcrypto in the build system.

Signed-off-by: Yuzhuo Jing &lt;yuzhuo@google.com&gt;
Signed-off-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Reviewed-by: Ian Rogers &lt;irogers@google.com&gt;
Link: https://lore.kernel.org/r/20250625202311.23244-5-ebiggers@kernel.org
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf build: The bfd features are opt-in, stop testing for them by default</title>
<updated>2025-06-24T17:27:50Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2025-06-20T21:24:35Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=970ae86307718c347aff8fe4bf6e780bcce26c58'/>
<id>urn:sha1:970ae86307718c347aff8fe4bf6e780bcce26c58</id>
<content type='text'>
These are leftovers noticed while updating a build container.

We don't need those so that test-all.c can build and thus speed up the
feature detection.

Test for those features only if the user asks for BUILD_NONDISTRO=1 to
build with libbfd.

Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Reviewed-by: James Clark &lt;james.clark@linaro.org&gt;
Reviewed-by: Ian Rogers &lt;irogers@google.com&gt;
Link: https://lore.kernel.org/r/20250620212435.93846-4-acme@kernel.org
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
</content>
</entry>
<entry>
<title>perf build: detect support for libbpf's emit_strings option</title>
<updated>2025-06-20T21:48:14Z</updated>
<author>
<name>Blake Jones</name>
<email>blakejones@google.com</email>
</author>
<published>2025-06-12T19:49:35Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1d0654b7fdc5431b85035f6e76b4bc57679575d8'/>
<id>urn:sha1:1d0654b7fdc5431b85035f6e76b4bc57679575d8</id>
<content type='text'>
This creates a config option that detects libbpf's ability to display
character arrays as strings, which was just added to the BPF tree
(https://git.kernel.org/bpf/bpf-next/c/87c9c79a02b4).

To test this change, I built perf (from later in this patch set) with:

 - static libbpf (default, using source from kernel tree)
 - dynamic libbpf (LIBBPF_DYNAMIC=1 LIBBPF_INCLUDE=/usr/local/include)

For both the static and dynamic versions, I used headers with and without
the ".emit_strings" option.

I verified that of the four resulting binaries, the two with
".emit_strings" would successfully record BPF_METADATA events, and the two
without wouldn't.  All four binaries would successfully display
BPF_METADATA events, because the relevant bit of libbpf code is only used
during "perf record".

Signed-off-by: Blake Jones &lt;blakejones@google.com&gt;
Link: https://lore.kernel.org/r/20250612194939.162730-2-blakejones@google.com
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
</content>
</entry>
<entry>
<title>tools/build: Remove some unused libbpf pre-1.0 feature test logic</title>
<updated>2025-06-09T18:18:19Z</updated>
<author>
<name>Ian Rogers</name>
<email>irogers@google.com</email>
</author>
<published>2025-06-03T22:13:58Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5ae6a303c22a07234108430b5fba869d5d1697e3'/>
<id>urn:sha1:5ae6a303c22a07234108430b5fba869d5d1697e3</id>
<content type='text'>
Commit 76a97cf2e169 ("perf build: Remove libbpf pre-1.0 feature
tests") removed the libbpf feature test logic used by perf in favor of
using LIBBPF_MAJOR_VERSION. Remove some build targets that should have
been removed as part of that clean up.

Fixes: 76a97cf2e169 ("perf build: Remove libbpf pre-1.0 feature tests")
Signed-off-by: Ian Rogers &lt;irogers@google.com&gt;
Link: https://lore.kernel.org/r/20250603221358.2562167-1-irogers@google.com
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
</content>
</entry>
<entry>
<title>tools build: Don't show libbfd build status as it is opt-in</title>
<updated>2025-04-10T13:45:30Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2025-04-08T18:03:11Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e0eb84cd518084582c0d1db5d904f31b16902fdc'/>
<id>urn:sha1:e0eb84cd518084582c0d1db5d904f31b16902fdc</id>
<content type='text'>
Since dd317df072071903 ("perf build: Make binutil libraries opt in")
doesn't try to build with binutils libraries, so showing that it is OFF
when building causes just distraction, remove it from FEATURES_DISPLAY.

For people that for some reason notice that there is always 'perf -vv',
a short hand for 'perf version --build-options' and 'perf check feature
libbfd' that now explains why it is not built:

  $ perf check feature libbfd
  libbfd: [ OFF ]  # HAVE_LIBBFD_SUPPORT ( tip: Deprecated, license incompatibility, use BUILD_NONDISTRO=1 and install binutils-dev[el] )
  $

Fixes: dd317df072071903 ("perf build: Make binutil libraries opt in")
Tested-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Dmitriy Vyukov &lt;dvyukov@google.com&gt;
Cc: Howard Chu &lt;howardchu95@gmail.com&gt;
Cc: Ian Rogers &lt;irogers@google.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Kan Liang &lt;kan.liang@linux.intel.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: https://lore.kernel.org/r/Z--pWmTHGb62_83e@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>tools build: Don't show libunwind build status as it is opt-in</title>
<updated>2025-04-10T13:44:55Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2025-04-08T18:03:11Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a3a40391292273cf78a7920c119cdc386d694c38'/>
<id>urn:sha1:a3a40391292273cf78a7920c119cdc386d694c38</id>
<content type='text'>
Since 13e17c9ff49119aa ("perf build: Make libunwind opt-in rather than
opt-out") doesn't try to build with libunwind, so showing that it is OFF
when building causes just distraction, remove it from FEATURES_DISPLAY.

For people that for some reason notice that there is always 'perf -vv',
a short hand for 'perf version --build-options' and 'perf check feature
libunwind' that now explains why it is not built:

  $ perf check feature libunwind
             libunwind: [ OFF ]  # HAVE_LIBUNWIND_SUPPORT ( tip: Deprecated, use LIBUNWIND=1 and install libunwind-dev[el] to build with it )
  $

Fixes: 13e17c9ff49119aa ("perf build: Make libunwind opt-in rather than opt-out")
Reported-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Tested-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Dmitriy Vyukov &lt;dvyukov@google.com&gt;
Cc: Howard Chu &lt;howardchu95@gmail.com&gt;
Cc: Ian Rogers &lt;irogers@google.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Kan Liang &lt;kan.liang@linux.intel.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: https://lore.kernel.org/r/Z--pWmTHGb62_83e@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>tools build: Don't set libunwind as available if test-all.c build succeeds</title>
<updated>2025-04-10T13:43:43Z</updated>
<author>
<name>Arnaldo Carvalho de Melo</name>
<email>acme@redhat.com</email>
</author>
<published>2025-04-04T18:37:45Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6559b83e4e71ba77461c8d6e6af7b89693c8e677'/>
<id>urn:sha1:6559b83e4e71ba77461c8d6e6af7b89693c8e677</id>
<content type='text'>
The tools/build/feature/test-all.c file tries to detect the expected,
most common set of libraries/features we expect to have available to
build perf with.

At some point libunwind was deemed not to be part of that set of
libries, but the patches making it to be opt-in ended up forgetting some
details, fix one more.

Testing it:

  $ rm -rf /tmp/build/$(basename $PWD)/ ; mkdir -p /tmp/build/$(basename $PWD)/
  $ rpm -q libunwind-devel
  libunwind-devel-1.8.0-3.fc40.x86_64
  $ make -k LIBUNWIND=1 CORESIGHT=1 O=/tmp/build/$(basename $PWD)/ -C tools/perf install-bin |&amp; grep unwind &amp;&amp; ldd ~/bin/perf | grep unwind
  ...                               libunwind: [ on  ]
    CC      /tmp/build/perf-tools-next/arch/x86/tests/dwarf-unwind.o
    CC      /tmp/build/perf-tools-next/arch/x86/util/unwind-libunwind.o
    CC      /tmp/build/perf-tools-next/util/arm64-frame-pointer-unwind-support.o
    CC      /tmp/build/perf-tools-next/tests/dwarf-unwind.o
    CC      /tmp/build/perf-tools-next/util/unwind-libunwind-local.o
    CC      /tmp/build/perf-tools-next/util/unwind-libunwind.o
	  libunwind-x86_64.so.8 =&gt; /lib64/libunwind-x86_64.so.8 (0x00007f615a549000)
	  libunwind.so.8 =&gt; /lib64/libunwind.so.8 (0x00007f615a52f000)
  $ sudo rpm -e libunwind-devel
  $ rm -rf /tmp/build/$(basename $PWD)/ ; mkdir -p /tmp/build/$(basename $PWD)/
  $ make -k LIBUNWIND=1 CORESIGHT=1 O=/tmp/build/$(basename $PWD)/ -C tools/perf install-bin |&amp; grep unwind &amp;&amp; ldd ~/bin/perf | grep unwind
  Makefile.config:653: No libunwind found. Please install libunwind-dev[el] &gt;= 1.1 and/or set LIBUNWIND_DIR
  ...                               libunwind: [ OFF ]
    CC      /tmp/build/perf-tools-next/arch/x86/tests/dwarf-unwind.o
    CC      /tmp/build/perf-tools-next/arch/x86/util/unwind-libdw.o
    CC      /tmp/build/perf-tools-next/util/arm64-frame-pointer-unwind-support.o
    CC      /tmp/build/perf-tools-next/tests/dwarf-unwind.o
    CC      /tmp/build/perf-tools-next/util/unwind-libdw.o
  $

Should be in a separate patch, but tired now, so also adding a message
about the need to use LIBUNWIND=1 in the output when its not available,
so done here as well.

So, now when the devel files are not available we get:

  $ make -k LIBUNWIND=1 CORESIGHT=1 O=/tmp/build/$(basename $PWD)/ -C tools/perf install-bin |&amp; grep unwind &amp;&amp; ldd ~/bin/perf | grep unwind
  Makefile.config:653: No libunwind found. Please install libunwind-dev[el] &gt;= 1.1 and/or set LIBUNWIND_DIR and set LIBUNWIND=1 in the make command line as it is opt-in now
  ...                               libunwind: [ OFF ]
  $

Fixes: 13e17c9ff49119aa ("perf build: Make libunwind opt-in rather than opt-out")
Reported-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Tested-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Dmitriy Vyukov &lt;dvyukov@google.com&gt;
Cc: Ian Rogers &lt;irogers@google.com&gt;
Cc: James Clark &lt;james.clark@linaro.org&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Kan Liang &lt;kan.liang@linux.intel.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: https://lore.kernel.org/r/Z_AnsW9oJzFbhIFC@x1
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'perf-tools-for-v6.15-2025-03-27' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools</title>
<updated>2025-03-31T15:52:33Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-03-31T15:52:33Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=802f0d58d52e8e34e08718479475ccdff0caffa0'/>
<id>urn:sha1:802f0d58d52e8e34e08718479475ccdff0caffa0</id>
<content type='text'>
Pull perf tools updates from Namhyung Kim:
 "perf record:

   - Introduce latency profiling using scheduler information.

     The latency profiling is to show impacts on wall-time rather than
     cpu-time. By tracking context switches, it can weight samples and
     find which part of the code contributed more to the execution
     latency.

     The value (period) of the sample is weighted by dividing it by the
     number of parallel execution at the moment. The parallelism is
     tracked in perf report with sched-switch records. This will reduce
     the portion that are run in parallel and in turn increase the
     portion of serial executions.

     For now, it's limited to profile processes, IOW system-wide
     profiling is not supported. You can add --latency option to enable
     this.

       $ perf record --latency -- make -C tools/perf

     I've run the above command for perf build which adds -j option to
     make with the number of CPUs in the system internally. Normally
     it'd show something like below:

       $ perf report -F overhead,comm
       ...
       #
       # Overhead  Command
       # ........  ...............
       #
           78.97%  cc1
            6.54%  python3
            4.21%  shellcheck
            3.28%  ld
            1.80%  as
            1.37%  cc1plus
            0.80%  sh
            0.62%  clang
            0.56%  gcc
            0.44%  perl
            0.39%  make
  	 ...

     The cc1 takes around 80% of the overhead as it's the actual
     compiler. However it runs in parallel so its contribution to
     latency may be less than that. Now, perf report will show both
     overhead and latency (if --latency was given at record time) like
     below:

       $ perf report -s comm
       ...
       #
       # Overhead   Latency  Command
       # ........  ........  ...............
       #
           78.97%    48.66%  cc1
            6.54%    25.68%  python3
            4.21%     0.39%  shellcheck
            3.28%    13.70%  ld
            1.80%     2.56%  as
            1.37%     3.08%  cc1plus
            0.80%     0.98%  sh
            0.62%     0.61%  clang
            0.56%     0.33%  gcc
            0.44%     1.71%  perl
            0.39%     0.83%  make
  	 ...

     You can see latency of cc1 goes down to around 50% and python3 and
     ld contribute a lot more than their overhead. You can use --latency
     option in perf report to get the same result but ordered by
     latency.

       $ perf report --latency -s comm

  perf report:

   - As a side effect of the latency profiling work, it adds a new
     output field 'latency' and a sort key 'parallelism'. The below is a
     result from my system with 64 CPUs. The build was well-parallelized
     but contained some serial portions.

       $ perf report -s parallelism
       ...
       #
       # Overhead   Latency  Parallelism
       # ........  ........  ...........
       #
           16.95%     1.54%           62
           13.38%     1.24%           61
           12.50%    70.47%            1
           11.81%     1.06%           63
            7.59%     0.71%           60
            4.33%    12.20%            2
            3.41%     0.33%           59
            2.05%     0.18%           64
            1.75%     1.09%            9
            1.64%     1.85%            5
            ...

   - Support Feodra mini-debuginfo which is a LZMA compressed symbol
     table inside ".gnu_debugdata" ELF section.

  perf annotate:

   - Add --code-with-type option to enable data-type profiling with the
     usual annotate output.

     Instead of focusing on data structure, it shows code annotation
     together with data type it accesses in case the instruction refers
     to a memory location (and it was able to resolve the target data
     type). Currently it only works with --stdio.

       $ perf annotate --stdio --code-with-type
       ...
        Percent |      Source code &amp; Disassembly of vmlinux for cpu/mem-loads,ldlat=30/pp (18 samples, percent: local period)
       ----------------------------------------------------------------------------------------------------------------------
                : 0                0xffffffff81050610 &lt;__fdget&gt;:
           0.00 :   ffffffff81050610:        callq   0xffffffff81c01b80 &lt;__fentry__&gt;           # data-type: (stack operation)
           0.00 :   ffffffff81050615:        pushq   %rbp              # data-type: (stack operation)
           0.00 :   ffffffff81050616:        movq    %rsp, %rbp
           0.00 :   ffffffff81050619:        pushq   %r15              # data-type: (stack operation)
           0.00 :   ffffffff8105061b:        pushq   %r14              # data-type: (stack operation)
           0.00 :   ffffffff8105061d:        pushq   %rbx              # data-type: (stack operation)
           0.00 :   ffffffff8105061e:        subq    $0x10, %rsp
           0.00 :   ffffffff81050622:        movl    %edi, %ebx
           0.00 :   ffffffff81050624:        movq    %gs:0x7efc4814(%rip), %rax  # 0x14e40 &lt;current_task&gt;              # data-type: struct task_struct* +0
           0.00 :   ffffffff8105062c:        movq    0x8d0(%rax), %r14         # data-type: struct task_struct +0x8d0 (files)
           0.00 :   ffffffff81050633:        movl    (%r14), %eax              # data-type: struct files_struct +0 (count.counter)
           0.00 :   ffffffff81050636:        cmpl    $0x1, %eax
           0.00 :   ffffffff81050639:        je      0xffffffff810506a9 &lt;__fdget+0x99&gt;
           0.00 :   ffffffff8105063b:        movq    0x20(%r14), %rcx          # data-type: struct files_struct +0x20 (fdt)
           0.00 :   ffffffff8105063f:        movl    (%rcx), %eax              # data-type: struct fdtable +0 (max_fds)
           0.00 :   ffffffff81050641:        cmpl    %ebx, %eax
           0.00 :   ffffffff81050643:        jbe     0xffffffff810506ef &lt;__fdget+0xdf&gt;
           0.00 :   ffffffff81050649:        movl    %ebx, %r15d
           5.56 :   ffffffff8105064c:        movq    0x8(%rcx), %rdx           # data-type: struct fdtable +0x8 (fd)
  	...

     The "# data-type:" part was added with this change. The first few
     entries are not very interesting. But later you can it accesses a
     couple of fields in the task_struct, files_struct and fdtable.

  perf trace:

   - Support syscall tracing for different ABI. For example it can trace
     system calls for 32-bit applications on 64-bit kernel
     transparently.

   - Add --summary-mode=total option to show global syscall summary. The
     default is 'thread' to show per-thread syscall summary.

  Python support:

   - Add more interfaces to 'perf' module to parse events, and config,
     enable or disable the event list properly so that it can implement
     basic functionalities purely in Python. There is an example code
     for these new interfaces in python/tracepoint.py.

   - Add mypy and pylint support to enable build time checking. Fix some
     code based on the findings from these tools.

  Internals:

   - Introduce io_dir__readdir() API to make directory traveral (usually
     for proc or sysfs) efficient with less memory footprint.

  JSON vendor events:

   - Add events and metrics for ARM Neoverse N3 and V3

   - Update events and metrics on various Intel CPUs

   - Add/update events for a number of SiFive processors"

* tag 'perf-tools-for-v6.15-2025-03-27' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools: (229 commits)
  perf bpf-filter: Fix a parsing error with comma
  perf report: Fix a memory leak for perf_env on AMD
  perf trace: Fix wrong size to bpf_map__update_elem call
  perf tools: annotate asm_pure_loop.S
  perf python: Fix setup.py mypy errors
  perf test: Address attr.py mypy error
  perf build: Add pylint build tests
  perf build: Add mypy build tests
  perf build: Rename TEST_LOGS to SHELL_TEST_LOGS
  tools/build: Don't pass test log files to linker
  perf bench sched pipe: fix enforced blocking reads in worker_thread
  perf tools: Fix is_compat_mode build break in ppc64
  perf build: filter all combinations of -flto for libperl
  perf vendor events arm64 AmpereOneX: Fix frontend_bound calculation
  perf vendor events arm64: AmpereOne/AmpereOneX: Mark LD_RETIRED impacted by errata
  perf trace: Fix evlist memory leak
  perf trace: Fix BTF memory leak
  perf trace: Make syscall table stable
  perf syscalltbl: Mask off ABI type for MIPS system calls
  perf build: Remove Makefile.syscalls
  ...
</content>
</entry>
<entry>
<title>Merge tag 'trace-tools-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace</title>
<updated>2025-03-28T00:03:01Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2025-03-28T00:03:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=4fa118e5b79fcc537dcb1a860ed319a6106935eb'/>
<id>urn:sha1:4fa118e5b79fcc537dcb1a860ed319a6106935eb</id>
<content type='text'>
Pull tracing tooling updates from Steven Rostedt:

 - Allow RTLA to collect data via BPF

   The current implementation of rtla uses libtracefs and libtraceevent
   to pull sample events generated by the timerlat tracer from the trace
   buffer. rtla then processes the sample by updating the histogram and
   summary (current, maximum, minimum, and sum values) as well as checks
   if tracing has been stopped due to threshold overflow.

   In use cases where a large number of samples is being generated, that
   is, with measurements running on many CPUs and with a low interval,
   this sample processing design causes a significant CPU load on the
   rtla side. Furthermore, with &gt;100 CPUs and 100us interval, rtla was
   reported as not being able to keep up with the samples and dropping
   most of them, leading to it being unusable.

   Change the way the timerlat trace processes samples by attaching a
   BPF program to the trace event using the BPF skeleton feature of
   bpftool. Unlike the current implementation, the BPF implementation
   does not check whether tracing is stopped (in BPF mode, tracing is
   always off to improve performance), but waits for a write to a BPF
   ringbuffer instead. This allows rtla to exit immediately when a
   threshold is violated, without waiting for the next iteration of the
   while loop.

   If the requirements for the BPF implementation are not met, either at
   build time or at run time, the current implementation is used as
   fallback. Which implementation is being used can be seen when running
   rtla timerlat with "-D" option. rtla can be forced to run in non-BPF
   mode by setting the RTLA_NO_BPF option to 1, for debugging purposes.

 - Fix LD_FLAGS from being dropped in build

 - Refactor code to remove duplication of save_trace_to_file

 - Always set options and do not rely on default settings

   Do not rely on the default kernel settings of the tracers when
   starting. They could have been changed by the user which gives
   inconsistent results. Always set the options that rtla expects.

 - Add creation of ctags and TAGS for traversing code

* tag 'trace-tools-v6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  rtla: Add the ability to create ctags and etags
  rtla/tests: Test setting default options
  rtla/tests: Reset osnoise options before check
  rtla: Always set all tracer options
  rtla/osnoise: Set OSNOISE_WORKLOAD to true
  rtla: Unify apply_config between top and hist
  rtla/osnoise: Unify params struct
  rtla: Fix segfault in save_trace_to_file call
  tools/build: Use SYSTEM_BPFTOOL for system bpftool
  rtla: Refactor save_trace_to_file
  tools/rv: Keep user LDFLAGS in build
  rtla/timerlat: Test BPF mode
  rtla/timerlat_top: Use BPF to collect samples
  rtla/timerlat_top: Move divisor to update
  rtla/timerlat_hist: Use BPF to collect samples
  rtla/timerlat: Add BPF skeleton to collect samples
  rtla: Add optional dependency on BPF tooling
  tools/build: Add bpftool-skeletons feature test
  rtla/timerlat: Unify params struct
</content>
</entry>
<entry>
<title>tools/build: Use SYSTEM_BPFTOOL for system bpftool</title>
<updated>2025-03-26T14:31:31Z</updated>
<author>
<name>Tomas Glozar</name>
<email>tglozar@redhat.com</email>
</author>
<published>2025-03-26T00:40:18Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=814d051ebed40b27285ab3c5e2454bd01a0f9631'/>
<id>urn:sha1:814d051ebed40b27285ab3c5e2454bd01a0f9631</id>
<content type='text'>
The feature test for system bpftool uses BPFTOOL as the variable to set
its path, defaulting to just "bpftool" if not set by the user.

This conflicts with selftests and a few other utilities, which expect
BPFTOOL to be set to the in-tree bpftool path by default. For example,
bpftool selftests fail to build:

$ make -C tools/testing/selftests/bpf/
make: Entering directory '/home/tglozar/dev/linux/tools/testing/selftests/bpf'

make: *** No rule to make target 'bpftool', needed by '/home/tglozar/dev/linux/tools/testing/selftests/bpf/tools/include/vmlinux.h'.  Stop.
make: Leaving directory '/home/tglozar/dev/linux/tools/testing/selftests/bpf'

Fix the problem by renaming the variable used for system bpftool from
BPFTOOL to SYSTEM_BPFTOOL, so that the new usage does not conflict with
the existing one of BPFTOOL.

Cc: John Kacur &lt;jkacur@redhat.com&gt;
Cc: Luis Goncalves &lt;lgoncalv@redhat.com&gt;
Link: https://lore.kernel.org/20250326004018.248357-1-tglozar@redhat.com
Fixes: 8a635c3856dd ("tools/build: Add bpftool-skeletons feature test")
Closes: https://lore.kernel.org/linux-kernel/5df6968a-2e5f-468e-b457-fc201535dd4c@linux.ibm.com/
Reported-by: Venkat Rao Bagalkote &lt;venkat88@linux.ibm.com&gt;
Tested-by: Venkat Rao Bagalkote &lt;venkat88@linux.ibm.com&gt;
Suggested-by: Quentin Monnet &lt;qmo@kernel.org&gt;
Acked-by: Quentin Monnet &lt;qmo@kernel.org&gt;
Signed-off-by: Tomas Glozar &lt;tglozar@redhat.com&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
</feed>
