commit | 46176a10399d6a9108705c73c2dcf32c90e7c439 | [log] [tgz] |
---|---|---|
author | Brenden Blanco <bblanco@plumgrid.com> | Tue Jul 07 13:05:22 2015 -0700 |
committer | Brenden Blanco <bblanco@plumgrid.com> | Tue Jul 07 13:07:54 2015 -0700 |
tree | 1f8fad603cff6c83a25d04ffb4dbb4487e01f77d | |
parent | 5950838c1f868800a62964e1568a380d7cb3323a [diff] |
Update README with install info, few cleanups * Add some examples to package * Fix bpf_trace_printk bug not supporting 0 format args * Make src_file arg loading a little bit more intelligent in BPF() * Update README with Hello, World step-by-step Signed-off-by: Brenden Blanco <bblanco@plumgrid.com>
This directory contains source code for BCC, a toolkit for creating small programs that can be dynamically loaded into a Linux kernel.
The compiler relies upon eBPF (Extended Berkeley Packet Filters), which is a feature in Linux kernels starting from 3.19. Currently, this compiler leverages features which are mostly available in Linux 4.1 and above.
BPF guarantees that the programs loaded into the kernel cannot crash, and cannot run forever, but yet BPF is general purpose enough to perform many arbitrary types of computation. Currently, it is possible to write a program in C that will compile into a valid BPF program, yet it is vastly easier to write a C program that will compile into invalid BPF (C is like that). The user won't know until trying to run the program whether it was valid or not.
With a BPF-specific frontend, one should be able to write in a language and receive feedback from the compiler on the validity as it pertains to a BPF backend. This toolkit aims to provide a frontend that can only create valid BPF programs while still harnessing its full flexibility.
Furthermore, current integrations with BPF have a kludgy workflow, sometimes involving compiling directly in a linux kernel source tree. This toolchain aims to minimize the time that a developer spends getting BPF compiled, and instead focus on the applications that can be written and the problems that can be solved with BPF.
The features of this toolkit include:
In the future, more bindings besides python will likely be supported. Feel free to add support for the language of your choice and send a pull request!
This toolchain is currently composed of two parts: a C wrapper around LLVM, and a Python API to interact with the running program. Later, we will go into more detail of how this all works.
First, we should include the BPF class from the bpf module:
from bpf import BPF
Since the C code is so short, we will embed it inside the python script.
The BPF program always takes at least one argument, which is a pointer to the context for this type of program. Different program types have different calling conventions, but for this one we don't care so void *
is fine.
prog = """ int hello(void *ctx) { bpf_trace_printk("Hello, World!\\n"); return 0; }; """ b = BPF(text=prog)
For this example, we will call the program every time fork()
is called by a userspace process. Underneath the hood, fork translates to the clone
syscall, so we will attach our program to the kernel symbol sys_clone
.
fn = b.load_func("hello", BPF.KPROBE) BPF.attach_kprobe(fn, "sys_clone")
The python process will then print the trace printk circular buffer until ctrl-c is pressed. The BPF program is removed from the kernel when the userspace process that loaded it closes the fd (or exits).
from subprocess import call try: call(["cat", "/sys/kernel/debug/tracing/trace_pipe"]) except KeyboardInterrupt: pass
Output:
bcc/examples$ sudo python hello_world.py python-7282 [002] d... 3757.488508: : Hello, World!
Walkthrough TBD, see Neighbor Sharing example for longer example.
To get started using this toolchain in binary format, one needs:
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_NET_CLS_BPF=m
[optional, for tc filters]CONFIG_NET_ACT_BPF=m
[optional, for tc actions]CONFIG_BPF_JIT=y
CONFIG_HAVE_BPF_JIT=y
CONFIG_BPF_EVENTS=y
[optional, for kprobes]As of this writing, binary packages for the above requirements are available in unstable formats. Both Ubuntu and Fedora have 4.2-rcX builds with the above flags defaulted to on. LLVM provides 3.7 Ubuntu packages (but not Fedora yet).
The build dependencies are captured in a Dockerfile, the output of which is a .deb for easy installation.
wget -qO- https://get.docker.com/ | sh
)git clone https://github.com/iovisor/bcc; cd bcc
docker build -t bcc -f Dockerfile.ubuntu .
docker run --rm -v /tmp:/mnt bcc sh -c "cp /root/bcc/build/*.deb /mnt"
sudo dpkg -i /tmp/libbcc*.deb
sudo python /usr/share/bcc/examples/hello_world.py
The build dependencies are captured in a Dockerfile, the output of which is a .rpm for easy installation. This version takes longer since LLVM needs to be compiled from source.
git clone https://github.com/iovisor/bcc; cd bcc
docker build -t bcc -f Dockerfile.fedora .
docker run --rm -v /tmp:/mnt bcc sh -c "cp /root/bcc/build/*.rpm /mnt"
sudo rpm -ivh /tmp/libbcc*.rpm
sudo python /usr/share/bcc/examples/hello_world.py
To build the toolchain from source, one needs:
LLVM 3.7 or newer, compiled with BPF support (default=on)
Clang 3.7, built from the same tree as LLVM
cmake, gcc (>=4.7), flex, bison
Add the LLVM binary repo to your apt sources
echo "deb http://llvm.org/apt/trusty/ llvm-toolchain-trusty main" \ | sudo tee /etc/apt/sources.list.d/llvm.list
wget -O - http://llvm.org/apt/llvm-snapshot.gpg.key | sudo apt-key add -
sudo apt-get update
Install build dependencies
sudo apt-get -y install bison build-essential cmake flex git \ libedit-dev python zlib1g-dev
Install LLVM and Clang development libs
sudo apt-get -y install libllvm3.7 llvm-3.7-dev libclang-3.7-dev
Install and compile BCC
git clone https://github.com/iovisor/bcc.git
mkdir bcc/build; cd bcc/build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr
make -j$(grep -c ^process /proc/cpuinfo)
sudo make install