Lines Matching +full:test +full:- +full:docs
10 Documentation/process/submitting-patches.rst. This document only describes
21 --------------------------------------------
48 ------------------------------------------------------------------------
49 A: BPF CI is GitHub based and hosted at https://github.com/kernel-patches/bpf.
55 - Create a fork of the aforementioned repository in your own account (one time
58 - Clone the fork locally, check out a new branch tracking either the bpf-next
59 or bpf branch, and apply your to-be-tested patches on top of it
61 - Push the local branch to your fork and create a pull request against
62 kernel-patches/bpf's bpf-next_base or bpf_base branch, respectively
68 Note furthermore that both base branches (bpf-next_base and bpf_base) will be
75 ------------------------------------------------------------
83 the changes and provide their Acked-by's to the patches.
86 -------------------------------------------------------------------------
111 ------------------------------------------------
117 * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/
119 The bpf tree itself is for fixes only, whereas bpf-next for features,
120 cleanups or other kind of improvements ("next-like" content). This is
121 analogous to net and net-next trees for networking. Both bpf and
122 bpf-next will only have a master branch in order to simplify against
127 into the bpf-next tree will make their way into net-next tree. net and
128 net-next are both run by David S. Miller. From there, they will go
130 process of net and net-next being merged into the mainline tree, see
132 Documentation/process/maintainer-netdev.rst.
138 net and net-next are always the main trees targeted for integration.
140 The pull requests will contain a high-level summary of the accumulated
142 following subject lines (``yyyy-mm-dd`` is the date of the pull
145 pull-request: bpf yyyy-mm-dd
146 pull-request: bpf-next yyyy-mm-dd
148 Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
149 ---------------------------------------------------------------------------------
152 documentation at Documentation/process/maintainer-netdev.rst,
154 patch is a fix or rather "next-like" content in order to let the
155 maintainers know whether it is targeted at bpf or bpf-next.
157 For fixes eventually landing in bpf -> net tree, the subject must
160 git format-patch --subject-prefix='PATCH bpf' start..finish
163 bpf-next -> net-next, the subject must look like::
165 git format-patch --subject-prefix='PATCH bpf-next' start..finish
168 or net directly, or bpf-next or net-next directly, it is not a
169 problem either if the subject line says net or net-next as target.
173 If it is clear that patches should go into bpf or bpf-next tree,
181 git format-patch --subject-prefix='PATCH bpf-next v2' start..finish
187 Q: What does it mean when a patch gets applied to bpf or bpf-next tree?
188 -----------------------------------------------------------------------
193 automatically get accepted into net or net-next trees eventually:
197 get included as-is, we will either apply a follow-up fix or drop
203 like net and net-next, and
205 ii) run extensive BPF test suite and
209 the patches end up in net or net-next tree, respectively, and
212 Documentation/process/maintainer-netdev.rst for additional information
216 -------------------------------------------------------------
221 Q: How often do you send pull requests to major kernel trees like net or net-next?
222 ----------------------------------------------------------------------------------
225 accumulate too many patches in bpf or bpf-next.
232 Q: Are patches applied to bpf-next when the merge window is open?
233 -----------------------------------------------------------------
234 A: For the time when the merge window is open, bpf-next will not be
235 processed. This is roughly analogous to net-next patch processing,
236 so feel free to read up on the netdev docs at
237 Documentation/process/maintainer-netdev.rst about further details.
240 your patch series once bpf-next is open again. Once Linus released
241 a ``v*-rc1`` after the merge window, we continue processing of bpf-next.
243 For non-subscribers to kernel mailing lists, there is also a status
244 page run by David S. Miller on net-next that provides guidance:
246 http://vger.kernel.org/~davem/net-next.html
248 Q: Verifier changes and test cases
249 ----------------------------------
250 Q: I made a BPF verifier change, do I need to add test cases for
254 it is absolutely necessary to add test cases to the BPF kernel
258 In particular, test_verifier.c is tracking a high number of BPF test
260 generate out of the restricted C code. Thus, adding test cases is
262 affect prior use-cases. Thus, treat those test cases as: verifier
267 ---------------------------------------
273 regularly run by various bots to test for kernel regressions.
275 The more test cases we add to BPF selftests, the better the coverage
282 ``samples/bpf/``, but advanced functional and corner-case testing rather
285 If your sample looks like a test case, then go for BPF kernel selftests
289 -----------------------------------------
297 ---------------------------------------------------
299 the convention is that those control-path related changes are added to
306 -----------------------------------------------------------
320 master]``' or '``[PATCH iproute2 net-next]``'. '``master``' or
321 '``net-next``' describes the target branch where the patch should be
322 applied to. Meaning, if kernel changes went into the net-next kernel
324 net-next branch, otherwise they can be targeted at master branch. The
325 iproute2 net-next branch will get merged into the master branch after
334 ------------------------------------------------------------------
335 A: When submitting patches, always take the time and properly test your
341 The same applies to fixes that target bpf-next, where the affected
342 commit is in net-next (or in some cases bpf-next). The ``Fixes:`` tag is
343 crucial in order to identify follow-up commits and tremendously helps
354 describing the use-case for the changes is a must.
362 ----------------------------------------
369 interpreter in case the in-kernel BPF JIT is enabled.
371 If you are unable to implement or test the required JIT changes for
377 Also always make sure to add BPF test cases (e.g. test_bpf.c and
379 broad test coverage and help run-time testing the various BPF JITs.
386 -----------------------------------------------
397 --------------------------------------------------------------------
399 the commit has already been applied in the related ``linux-*.y`` branches:
401 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/
410 Documentation/process/maintainer-netdev.rst.
413 ----------------------------------------------------------------------
422 -------------------------------------------------------------------
426 the netdev docs at Documentation/process/maintainer-netdev.rst.
430 with a note, for example, under the ``---`` part of the patch which does
435 -----------------------
454 ---------------------------
456 the BPF selftests_ suite in order to test BPF functionality (current
468 information of test successes and failures::
477 See :doc:`kernel selftest documentation </dev-tools/kselftest>`
481 under test should match the config file fragment in
484 Finally to ensure support for latest BPF Type Format features -
485 discussed in Documentation/bpf/btf.rst - pahole version 1.16
495 use "git submodule update --init --recursive" to update.
509 ---------------------------------------------------------------------
515 test cases and are constantly updated with new BPF test sequences, or
523 -----------------------------------------
527 so for the majority of use-cases it is not required to compile LLVM by
531 ``llc --version``, make sure BPF targets are listed. Example::
533 $ llc --version
537 Default target: x86_64-unknown-linux-gnu
541 aarch64 - AArch64 (little endian)
542 bpf - BPF (host endian)
543 bpfeb - BPF (big endian)
544 bpfel - BPF (little endian)
545 x86 - 32-bit X86: Pentium-Pro and above
546 x86-64 - 64-bit X86: EM64T and AMD64
556 --------------------------------------------------
559 manager, usually the package is ninja or ninja-build.
561 You need ninja, cmake and gcc-c++ as build requisites for LLVM. Once you
565 $ git clone https://github.com/llvm/llvm-project.git
566 $ mkdir -p llvm-project/llvm/build
567 $ cd llvm-project/llvm/build
568 $ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
569 -DLLVM_ENABLE_PROJECTS="clang" \
570 -DCMAKE_BUILD_TYPE=Release \
571 -DLLVM_BUILD_RUNTIME=OFF
577 Set ``-DLLVM_TARGETS_TO_BUILD`` equal to the target you wish to build, you
578 will find a full list of targets within the llvm-project/llvm/lib/Target
582 ----------------------------
609 ------------------------------------------
613 A: LLVM has a ``-mcpu`` selector for the BPF back end in order to allow
619 LLVM has an option to select ``-mcpu=probe`` where it will probe the host
623 For cross-compilation, a specific version can be select manually as well ::
625 $ llc -march bpf -mcpu=help
628 generic - Select the generic processor.
629 probe - Select the probe processor.
630 v1 - Select the v1 processor.
631 v2 - Select the v2 processor.
636 extensions such that ``-mcpu=probe`` users can benefit from the
642 By the way, the BPF kernel selftests run with ``-mcpu=probe`` for better
643 test coverage.
646 -----------------------------
647 Q: In some cases clang flag ``--target=bpf`` is used but in other cases the
652 independent, ``--target=<arch>`` still has some impact on generated code:
654 - BPF program may recursively include header file(s) with file scope
659 - When compiled without ``-g``, additional elf sections, e.g.,
663 - The default target may turn a C switch statement into a switch table
667 The clang option ``-fno-jump-tables`` can be used to disable
670 - For clang ``--target=bpf``, it is guaranteed that pointer or long /
680 Otherwise, ``clang --target=bpf`` is generally recommended.
684 - Your program includes a header file, e.g., ptrace.h, which eventually
687 - You can add ``-fno-jump-tables`` to work around the switch table issue.
692 - Your program uses data structures with pointer or long / unsigned long
696 the BPF architecture, e.g. 64-bit. An example of this is
697 BPF_PROG_TYPE_SK_MSG require ``--target=bpf``