Lines Matching +full:pulled +full:- +full:up
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
125 Accumulated BPF patches in the bpf tree will regularly get pulled
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
129 into the kernel mainline tree run by Linus Torvalds. To read up on the
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,
153 so please read up on it. The subject line must indicate whether the
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.
170 It is eventually up to the maintainers to do the delegation of
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,
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
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
328 Like BPF, the patches end up in patchwork under the netdev project and
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
347 time and properly write up a high quality commit message, it is
354 describing the use-case for the changes is a must.
362 ----------------------------------------
366 A: We try hard to keep all BPF JITs up to date such that the same user
369 interpreter in case the in-kernel BPF JIT is enabled.
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/
404 netdev kernel mailing list in Cc and ask for the fix to be queued up:
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 -----------------------
440 are queued up for stable submission under:
454 ---------------------------
477 See :doc:`kernel selftest documentation </dev-tools/kselftest>`
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 ---------------------------------------------------------------------
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
562 have that set up, proceed with building the latest LLVM and clang version
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 ----------------------------
594 Therefore, please make sure to bring them up at netdev kernel mailing
609 ------------------------------------------
613 A: LLVM has a ``-mcpu`` selector for the BPF back end in order to allow
618 LLVM has an option to select ``-mcpu=probe`` where it will probe the host
622 For cross-compilation, a specific version can be select manually as well ::
624 $ llc -march bpf -mcpu=help
627 generic - Select the generic processor.
628 probe - Select the probe processor.
629 v1 - Select the v1 processor.
630 v2 - Select the v2 processor.
635 extensions such that ``-mcpu=probe`` users can benefit from the
641 By the way, the BPF kernel selftests run with ``-mcpu=probe`` for better
645 -----------------------------
646 Q: In some cases clang flag ``--target=bpf`` is used but in other cases the
651 independent, ``--target=<arch>`` still has some impact on generated code:
653 - BPF program may recursively include header file(s) with file scope
658 - When compiled without ``-g``, additional elf sections, e.g.,
662 - The default target may turn a C switch statement into a switch table
666 The clang option ``-fno-jump-tables`` can be used to disable
669 - For clang ``--target=bpf``, it is guaranteed that pointer or long /
679 Otherwise, ``clang --target=bpf`` is generally recommended.
683 - Your program includes a header file, e.g., ptrace.h, which eventually
686 - You can add ``-fno-jump-tables`` to work around the switch table issue.
691 - Your program uses data structures with pointer or long / unsigned long
695 the BPF architecture, e.g. 64-bit. An example of this is
696 BPF_PROG_TYPE_SK_MSG require ``--target=bpf``