Lines Matching +full:functional +full:- +full:system +full:- +full:fedora
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
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,
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
249 ----------------------------------
262 affect prior use-cases. Thus, treat those test cases as: verifier
267 ---------------------------------------
282 ``samples/bpf/``, but advanced functional and corner-case testing rather
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 ------------------------------------------------------------------
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.
379 broad test coverage and help run-time testing the various BPF JITs.
389 --------------------------------------------------------------------
391 the commit has already been applied in the related ``linux-*.y`` branches:
393 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/
402 Documentation/process/maintainer-netdev.rst.
405 ----------------------------------------------------------------------
414 -------------------------------------------------------------------
418 the netdev docs at Documentation/process/maintainer-netdev.rst.
422 with a note, for example, under the ``---`` part of the patch which does
427 -----------------------
446 ---------------------------
469 See :doc:`kernel selftest documentation </dev-tools/kselftest>`
476 Finally to ensure support for latest BPF Type Format features -
477 discussed in Documentation/bpf/btf.rst - pahole version 1.16
487 use "git submodule update --init --recursive" to update.
498 Fedora, Gentoo.
501 ---------------------------------------------------------------------
515 -----------------------------------------
519 so for the majority of use-cases it is not required to compile LLVM by
523 ``llc --version``, make sure BPF targets are listed. Example::
525 $ llc --version
529 Default target: x86_64-unknown-linux-gnu
533 aarch64 - AArch64 (little endian)
534 bpf - BPF (host endian)
535 bpfeb - BPF (big endian)
536 bpfel - BPF (little endian)
537 x86 - 32-bit X86: Pentium-Pro and above
538 x86-64 - 64-bit X86: EM64T and AMD64
548 --------------------------------------------------
550 use the Ninja build system, you can find it in your system's package
551 manager, usually the package is ninja or ninja-build.
553 You need ninja, cmake and gcc-c++ as build requisites for LLVM. Once you
557 $ git clone https://github.com/llvm/llvm-project.git
558 $ mkdir -p llvm-project/llvm/build
559 $ cd llvm-project/llvm/build
560 $ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
561 -DLLVM_ENABLE_PROJECTS="clang" \
562 -DCMAKE_BUILD_TYPE=Release \
563 -DLLVM_BUILD_RUNTIME=OFF
569 Set ``-DLLVM_TARGETS_TO_BUILD`` equal to the target you wish to build, you
570 will find a full list of targets within the llvm-project/llvm/lib/Target
574 ----------------------------
601 ------------------------------------------
605 A: LLVM has a ``-mcpu`` selector for the BPF back end in order to allow
610 LLVM has an option to select ``-mcpu=probe`` where it will probe the host
614 For cross-compilation, a specific version can be select manually as well ::
616 $ llc -march bpf -mcpu=help
619 generic - Select the generic processor.
620 probe - Select the probe processor.
621 v1 - Select the v1 processor.
622 v2 - Select the v2 processor.
627 extensions such that ``-mcpu=probe`` users can benefit from the
633 By the way, the BPF kernel selftests run with ``-mcpu=probe`` for better
637 -----------------------------
638 Q: In some cases clang flag ``--target=bpf`` is used but in other cases the
643 independent, ``--target=<arch>`` still has some impact on generated code:
645 - BPF program may recursively include header file(s) with file scope
650 - When compiled without ``-g``, additional elf sections, e.g.,
654 - The default target may turn a C switch statement into a switch table
658 The clang option ``-fno-jump-tables`` can be used to disable
661 - For clang ``--target=bpf``, it is guaranteed that pointer or long /
671 Otherwise, ``clang --target=bpf`` is generally recommended.
675 - Your program includes a header file, e.g., ptrace.h, which eventually
678 - You can add ``-fno-jump-tables`` to work around the switch table issue.
683 - Your program uses data structures with pointer or long / unsigned long
687 the BPF architecture, e.g. 64-bit. An example of this is
688 BPF_PROG_TYPE_SK_MSG require ``--target=bpf``