docs/bpf: minor casing/punctuation fixes

Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

kernel os linux

Fix few casing and punctuation glitches.

Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

authored by

Andrii Nakryiko and committed by

Daniel Borkmann 7 years ago 46604676 9ab5305d

+13 -13

2 changed files

expand all

Documentation

bpf

bpf_design_QA.rst

networking

filter.txt

+12 -12

Documentation/bpf/bpf_design_QA.rst

··· 36 36 defines calling convention that is compatible with C calling 37 37 convention of the linux kernel on those architectures. 38 38 39 - Q: can multiple return values be supported in the future? 39 + Q: Can multiple return values be supported in the future? 40 40 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 41 41 A: NO. BPF allows only register R0 to be used as return value. 42 42 43 - Q: can more than 5 function arguments be supported in the future? 43 + Q: Can more than 5 function arguments be supported in the future? 44 44 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 45 45 A: NO. BPF calling convention only allows registers R1-R5 to be used 46 46 as arguments. BPF is not a standalone instruction set. 47 47 (unlike x64 ISA that allows msft, cdecl and other conventions) 48 48 49 - Q: can BPF programs access instruction pointer or return address? 49 + Q: Can BPF programs access instruction pointer or return address? 50 50 ----------------------------------------------------------------- 51 51 A: NO. 52 52 53 - Q: can BPF programs access stack pointer ? 53 + Q: Can BPF programs access stack pointer ? 54 54 ------------------------------------------ 55 55 A: NO. 56 56 57 57 Only frame pointer (register R10) is accessible. 58 58 From compiler point of view it's necessary to have stack pointer. 59 - For example LLVM defines register R11 as stack pointer in its 59 + For example, LLVM defines register R11 as stack pointer in its 60 60 BPF backend, but it makes sure that generated code never uses it. 61 61 62 62 Q: Does C-calling convention diminishes possible use cases? ··· 66 66 BPF design forces addition of major functionality in the form 67 67 of kernel helper functions and kernel objects like BPF maps with 68 68 seamless interoperability between them. It lets kernel call into 69 - BPF programs and programs call kernel helpers with zero overhead. 70 - As all of them were native C code. That is particularly the case 69 + BPF programs and programs call kernel helpers with zero overhead, 70 + as all of them were native C code. That is particularly the case 71 71 for JITed BPF programs that are indistinguishable from 72 72 native kernel C code. 73 73 ··· 75 75 ------------------------------------------------------------------------ 76 76 A: Soft yes. 77 77 78 - At least for now until BPF core has support for 78 + At least for now, until BPF core has support for 79 79 bpf-to-bpf calls, indirect calls, loops, global variables, 80 - jump tables, read only sections and all other normal constructs 80 + jump tables, read-only sections, and all other normal constructs 81 81 that C code can produce. 82 82 83 83 Q: Can loops be supported in a safe way? ··· 109 109 A: This was necessary to avoid introducing flags into ISA which are 110 110 impossible to make generic and efficient across CPU architectures. 111 111 112 - Q: why BPF_DIV instruction doesn't map to x64 div? 112 + Q: Why BPF_DIV instruction doesn't map to x64 div? 113 113 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 114 114 A: Because if we picked one-to-one relationship to x64 it would have made 115 115 it more complicated to support on arm64 and other archs. Also it 116 116 needs div-by-zero runtime check. 117 117 118 - Q: why there is no BPF_SDIV for signed divide operation? 118 + Q: Why there is no BPF_SDIV for signed divide operation? 119 119 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 120 120 A: Because it would be rarely used. llvm errors in such case and 121 - prints a suggestion to use unsigned divide instead 121 + prints a suggestion to use unsigned divide instead. 122 122 123 123 Q: Why BPF has implicit prologue and epilogue? 124 124 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+1 -1

Documentation/networking/filter.txt

··· 829 829 is not used by socket filters either, but more complex filters may be running 830 830 out of registers and would have to resort to spill/fill to stack. 831 831 832 - Internal BPF can used as generic assembler for last step performance 832 + Internal BPF can be used as a generic assembler for last step performance 833 833 optimizations, socket filters and seccomp are using it as assembler. Tracing 834 834 filters may use it as assembler to generate code from kernel. In kernel usage 835 835 may not be bounded by security considerations, since generated internal BPF code