| commit | f275d3dbbccd2ec0f987a96ef64ac076691826f4 | [log] [tgz] |
|---|---|---|
| author | Brenden Blanco <bblanco@plumgrid.com> | Mon Jul 06 23:41:23 2015 -0700 |
| committer | Brenden Blanco <bblanco@plumgrid.com> | Mon Jul 06 23:41:23 2015 -0700 |
| tree | 893de73c374408110ed64717c8d54ed658dc809f | |
| parent | 439a9f30fa9ea7ca0996f432116570957d80228f [diff] |
Add multiple build support styles * Add RPM and DEB packaging targets (using CPack from CMake) to build binary packages for Fedora and Ubuntu targets. * Add Docker build scripts for each of the above that run the build in the right environment (assuming docker is available). - In Ubuntu, build against the LLVM 3.7 nightly snapshots - In Fedora, build against LLVM 3.7 from git (takes longer) * Depending on packages installed on the build machine, it may be possible to cross-package for other targets without invoking Docker. * Re-introduce src/cc/compat directory to keep the build stable for the time being. Similarly, it was necessary to #define some ugly constants that should eventually show up in libc. * Add a few simple version checks to allow a partially working (really tracing only) libbcc in 4.1 kernels. TODO (followup commit): Re-work the READMEs 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.
The features of this toolkit include:
To get started using this toolchain, one needs:
CONFIG_BPF=yCONFIG_BPF_SYSCALL=yCONFIG_NET_CLS_BPF=m [optional, for tc filters]CONFIG_NET_ACT_BPF=m [optional, for tc actions]CONFIG_BPF_JIT=yCONFIG_HAVE_BPF_JIT=yCONFIG_BPF_EVENTS=y [optional, for kprobes]See https://github.com/iovisor/bcc/scripts/README.md for a script that can be used to set up a libvirt VM with the required dependencies.
If the LLVM and Linux kernel requirements are satisfied, testing out this package should be as simple as:
git clone https://github.com/iovisor/bcc.git cd bcc; mkdir build; cd build cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_PREFIX_PATH=/opt/local/llvm make -j$(grep -c ^processor /proc/cpuinfo) sudo make install cd ../ sudo python examples/hello_world.py <ctrl-C>
Change CMAKE_PREFIX_PATH if llvm is installed elsewhere.
Since packaging is currently not available, one can cleanup the collateral of bcc by doing:
sudo rm -rf /usr/{lib/libbpf.prog.so,include/bcc,share/bcc}
sudo pip uninstall bpf
See http://llvm.org/docs/GettingStarted.html for the full guide.
The short version:
git clone https://github.com/llvm-mirror/llvm.git llvm git clone https://github.com/llvm-mirror/clang.git llvm/tools/clang mkdir llvm/build/ cd llvm/build/ cmake .. -DCMAKE_INSTALL_PREFIX=/opt/local/llvm make -j$(grep -c ^processor /proc/cpuinfo) sudo make install