Documentation/bpf/bpf_design_QA.rst

Source file repositories/reference/linux-study-clean/Documentation/bpf/bpf_design_QA.rst

File Facts

System
Linux kernel
Corpus path
Documentation/bpf/bpf_design_QA.rst
Extension
.rst
Size
16034 bytes
Lines
352
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: exported/initcall integration point
Status
integration implementation candidate

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

==============
BPF Design Q&A
==============

BPF extensibility and applicability to networking, tracing, security
in the linux kernel and several user space implementations of BPF
virtual machine led to a number of misunderstanding on what BPF actually is.
This short QA is an attempt to address that and outline a direction
of where BPF is heading long term.

.. contents::
    :local:
    :depth: 3

Questions and Answers
=====================

Q: Is BPF a generic instruction set similar to x64 and arm64?
-------------------------------------------------------------
A: NO.

Q: Is BPF a generic virtual machine ?
-------------------------------------
A: NO.

BPF is generic instruction set *with* C calling convention.
-----------------------------------------------------------

Q: Why C calling convention was chosen?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A: Because BPF programs are designed to run in the linux kernel
which is written in C, hence BPF defines instruction set compatible
with two most used architectures x64 and arm64 (and takes into
consideration important quirks of other architectures) and
defines calling convention that is compatible with C calling
convention of the linux kernel on those architectures.

Q: Can multiple return values be supported in the future?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A: NO. BPF allows only register R0 to be used as return value.

Q: Can more than 5 function arguments be supported in the future?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A: NO. BPF calling convention only allows registers R1-R5 to be used
as arguments. BPF is not a standalone instruction set.
(unlike x64 ISA that allows msft, cdecl and other conventions)

Q: Can BPF programs access instruction pointer or return address?
-----------------------------------------------------------------
A: NO.

Q: Can BPF programs access stack pointer ?
------------------------------------------
A: NO.

Only frame pointer (register R10) is accessible.
From compiler point of view it's necessary to have stack pointer.
For example, LLVM defines register R11 as stack pointer in its
BPF backend, but it makes sure that generated code never uses it.

Q: Does C-calling convention diminishes possible use cases?
-----------------------------------------------------------
A: YES.

BPF design forces addition of major functionality in the form
of kernel helper functions and kernel objects like BPF maps with
seamless interoperability between them. It lets kernel call into
BPF programs and programs call kernel helpers with zero overhead,
as all of them were native C code. That is particularly the case

Annotation

Implementation Notes