Remove bpfilter daemon and consolidate every feature in libbpfilter

CLAUDE.md

@@ -5,9 +5,8 @@
 bpfilter is an eBPF-based packet filtering framework that translates filtering rules into optimized BPF programs. Licensed under GPLv2, maintained by Meta.
 
 **Components:**
-- `libbpfilter` - Core library with public API for filtering logic
-- `bpfilter` - Daemon that generates and manages BPF programs
-- `bfcli` - CLI for defining filtering rules
+- `libbpfilter` - Core library containing all filtering logic, BPF code generation, and program lifecycle management
+- `bfcli` - CLI for defining and managing filtering rules via `libbpfilter`
 
 **Requirements:** Linux 6.6+, libbpf 1.2+
 
@@ -17,13 +16,12 @@ bpfilter is an eBPF-based packet filtering framework that translates filtering r
 src/
 ├── libbpfilter/          # Core library (shared object)
 │   ├── include/bpfilter/ # Public API headers
-│   └── *.c               # Implementation (chain, matcher, rule, hook, set, bpf, btf...)
-├── bpfilter/             # Daemon
 │   ├── cgen/             # BPF code generation engine
 │   │   ├── matcher/      # Packet matcher codegen (ip4, ip6, tcp, udp, icmp, meta, set)
 │   │   └── prog/         # Program linking (link, map)
 │   ├── xlate.c           # Rule translation
 │   └── bpf/              # eBPF stub programs
+│   └── *.c               # Implementation (chain, matcher, rule, hook, set, bpf, btf, ctx...)
 ├── bfcli/                # CLI (parser.y, lexer.l, opts, print, chain, ruleset)
 └── external/             # External deps (mpack)
 
@@ -35,7 +33,7 @@ tests/
 └── harness/              # Test utilities (test.h, mock.h, fake.h)
 
 doc/
-├── usage/                # User guides (bfcli, daemon)
+├── usage/                # User guides (bfcli)
 └── developers/           # Dev docs (build, style, tests, modules/)
 ```
 
@@ -114,15 +112,15 @@ Use `#pragma once` for header guards. Prefer forward declarations over includes
 
 ### Commit messages
 Format: `component: subcomponent: short description`
-- Components: `lib`, `daemon`, `cli`, `tests`, `build`, `tools`, `doc`
+- Components: `lib`, `cli`, `tests`, `build`, `tools`, `doc`
 - Lowercase, imperative mood, no period, under 72 chars
 - Description explains "why", code shows "what"
 - No reference to Claude or Claude as co-author
 
 Examples:
 ```
 lib: matcher: add meta.flow_hash matcher
-daemon: cgen: link: add support for dual-stack Netfilter chains
+lib: cgen: link: add support for dual-stack Netfilter chains
 tests: e2e: fix end-to-end tests leaving files behind
 ```
 

CMakeLists.txt

@@ -90,14 +90,13 @@ target_link_options(bf_global_flags_cxx
 
 add_subdirectory(src/libbpfilter)
 add_subdirectory(src/bfcli)
-add_subdirectory(src/bpfilter)
 
 if (NOT ${NO_DOCS})
     add_subdirectory(doc)
 endif ()
 
 if (NOT ${NO_TESTS})
-    set(CMAKE_CTEST_ARGUMENTS "--output-on-failure")
+    set(CMAKE_CTEST_ARGUMENTS "--output-on-failure;--label-exclude;fuzzing")
     enable_testing()
     add_subdirectory(tests)
 endif ()

README.md

@@ -32,7 +32,7 @@
 - **Low overhead**: minimal resource consumption with maximized efficiency
 - **Developer-friendly**: clean architecture with clear separation of components
 
-**bpfilter** combines three components: a CLI that allows users to define filtering rules in human-readable text, a daemon that converts these rules into efficient BPF programs, and a library that facilitates seamless communication between applications and the filtering subsystem.
+**bpfilter** combines two components: a core library that translates filtering rules into efficient BPF programs and manages their lifecycle, and a CLI that allows users to define and manage filtering rules in human-readable text.
 
 Want to know more about **bpfilter**? Check the [user's guide](https://bpfilter.io/usage/index.html), the [developer documentation](https://bpfilter.io/developers/build.html), our [contributing guide](https://bpfilter.io/developers/contributing.html), or watch our latest [public talk](https://www.youtube.com/watch?v=fzaPEm4PXn0)!
 
@@ -61,9 +61,6 @@ make -C $BUILD_DIR
 ### Usage
 
 ```shell
-# Start the daemon
-sudo $BUILD_DIR/output/sbin/bpfilter
-
 # Count the number of ping coming to interface #2
 sudo $BUILD_DIR/output/sbin/bfcli ruleset set --from-str "chain my_chain BF_HOOK_XDP{ifindex=2} ACCEPT rule ip4.proto icmp counter ACCEPT"
 ```

doc/CMakeLists.txt

@@ -80,7 +80,6 @@ list(FILTER bf_srcs EXCLUDE REGEX "${CMAKE_SOURCE_DIR}/src/external/.*")
 set(doc_srcs
 	${CMAKE_CURRENT_SOURCE_DIR}/index.rst
 	${CMAKE_CURRENT_SOURCE_DIR}/usage/bfcli.rst
-	${CMAKE_CURRENT_SOURCE_DIR}/usage/daemon.rst
 	${CMAKE_CURRENT_SOURCE_DIR}/usage/index.rst
 	${CMAKE_CURRENT_SOURCE_DIR}/developers/build.rst
 	${CMAKE_CURRENT_SOURCE_DIR}/developers/contributing.rst
@@ -89,7 +88,6 @@ set(doc_srcs
 	${CMAKE_CURRENT_SOURCE_DIR}/developers/style.rst
 	${CMAKE_CURRENT_SOURCE_DIR}/developers/tests.rst
 	${CMAKE_CURRENT_SOURCE_DIR}/developers/modules/index.rst
-	${CMAKE_CURRENT_SOURCE_DIR}/developers/modules/bpfilter/bpfilter.rst
 	${CMAKE_CURRENT_SOURCE_DIR}/developers/modules/libbpfilter/libbpfilter.rst
 	${CMAKE_CURRENT_SOURCE_DIR}/external/benchmarks/index.rst
 	${CMAKE_CURRENT_SOURCE_DIR}/external/coverage/index.rst

doc/developers/build.rst

@@ -1,7 +1,7 @@
 Build from sources
 ==================
 
-This document describes the process to build ``bpfilter`` from sources. While ``bpfilter`` can be built on most systems, a recent (6.6+) Linux kernel is required with ``libbpf`` 1.2+ to run the ``bpfilter`` daemon. ``bpfilter`` officially supports Fedora 40+, CentOS Stream 9+, and Ubuntu 24.04+. There is also a nix flake which supports all the make targets.
+This document describes the process to build ``bpfilter`` from sources. While ``bpfilter`` can be built on most systems, a recent (6.6+) Linux kernel is required with ``libbpf`` 1.2+ to run ``bpfilter``. ``bpfilter`` officially supports Fedora 40+, CentOS Stream 9+, and Ubuntu 24.04+. There is also a nix flake which supports all the make targets except for ``doc``.
 
 If you want to perform a full build of ``bpfilter`` (including all test tests, code check, benchmarks, and documentation), the following dependencies are required:
 
@@ -101,9 +101,10 @@ The usual CMake options are allowed (e.g. ``CMAKE_BUILD_TYPE``, ``CMAKE_INSTALL_
 
 A full configuration (without any part disabled) will provide the following targets:
 
-- ``core``, ``bpfilter``, ``libbpfilter``, ``bfcli``: the ``bpfilter`` binaries.
+- ``core``, ``libbpfilter``, ``bfcli``: the ``bpfilter`` binaries.
 - ``test_bin``: build the binaries needed to run the tests (below).
-- ``test``: run all the tests. This command will run ``unit``, ``check``, ``e2e``, ``fuzzing``, and ``integration`` targets. See :doc:`tests` for more information.
+- ``test``: run all the tests. This command will run ``unit``, ``check``, ``e2e``, and ``integration`` targets. See :doc:`tests` for more information.
+- ``fuzzing``: fuzz the CLI parser for 60 seconds.
 - ``check``: run ``clang-tidy`` and ``clang-format`` against the source files.
 - ``benchmarks``: run the benchmarks on ``bpfilter``.
 

doc/developers/modules/index.rst

@@ -6,12 +6,10 @@ Modules
    :caption: Modules
 
    libbpfilter/libbpfilter
-   bpfilter/bpfilter
 
-``bpfilter`` is composed of multiple modules depending on each other. Splitting the project in different modules allows for the source code to be efficiently reused, be it for ``bfcli``, ``bpfilter``'s daemon, or ``libbpfilter``:
+``bpfilter`` is composed of multiple modules depending on each other. Splitting the project in different modules allows for the source code to be efficiently reused:
 
-- ``core``: core definitions used by the daemon, ``bfcli``, and ``libbpfilter``.
-- ``bpfilter``: daemon logic, including deserializing data sent by the client into ``bpfilter``'s internal format, and the BPF bytecode generation logic.
-- ``bfcli``: generic client to communicate with the daemon.
-- ``libbpfilter``: static and shared library to communicate with the daemon.
+- ``core``: core definitions used by ``bfcli`` and ``libbpfilter``.
+- ``libbpfilter``: core library containing all filtering logic, BPF code generation, and program lifecycle management.
+- ``bfcli``: CLI tool for defining and managing filtering rules via ``libbpfilter``.
 - ``external``: non-``bpfilter`` code, imported into the project to provide consistent external definitions.

doc/developers/modules/libbpfilter/libbpfilter.rst

@@ -4,13 +4,6 @@ libbpfilter
 .. doxygenfile:: bpfilter/bpfilter.h
 
 
-Namespaces
-----------
-
-.. doxygenfile:: ns.h
-   :sections: briefdescription detaileddescription typedef struct innerclass enum var define func
-
-
 Pack
 ----
 

doc/developers/style.rst

@@ -341,7 +341,7 @@ Commit messages should be formatted as ``component: subcomponent: short descript
 - No period at the end
 - Keep under 72 characters
 
-Components are ``lib``, ``daemon``, ``cli``, ``tests``, ``build``, ``tools``, ``doc``. Subcomponents reflect the directory structure (e.g., ``tests: e2e:``, ``daemon: cgen: link:``). If you're unsure, check the commit history for a hint.
+Components are ``lib``, ``cli``, ``tests``, ``build``, ``tools``, ``doc``. Subcomponents reflect the directory structure (e.g., ``tests: e2e:``, ``lib: cgen: link:``). If you're unsure, check the commit history for a hint.
 
 Examples:
 

doc/developers/tests.rst

@@ -84,7 +84,7 @@ End-to-end tests are designed to validate bpfilter's behaviour as seen by the us
 
 **Example**
 
-``e2e_test_util.sh`` provides functions to create a sandboxed environment and start the ``bpfilter`` daemon. Here is an example of a simple end-to-end test that creates a sandbox and starts ``bpfilter``:
+``e2e_test_util.sh`` provides functions to create a sandboxed environment. Here is an example of a simple end-to-end test that creates a sandbox:
 
 .. code-block:: shell
 
@@ -96,7 +96,6 @@ End-to-end tests are designed to validate bpfilter's behaviour as seen by the us
     . "$(dirname "$0")"/../e2e_test_util.sh
 
     make_sandbox
-    start_bpfilter
 
     # Ping the sandbox's IPv4 address from the sandboxed namespace
     ${FROM_NS} ping -c 1 -W 0.1 ${NS_IP_ADDR}

doc/index.rst

@@ -61,6 +61,6 @@
 - **Low overhead**: minimal resource consumption with maximized efficiency
 - **Developer-friendly**: clean architecture with clear separation of components
 
-**bpfilter** combines three components: a CLI that allows users to define filtering rules in human-readable text, a daemon that converts these rules into efficient BPF programs, and a library that facilitates seamless communication between applications and the filtering subsystem.
+**bpfilter** combines two components: ``bfcli``, a CLI that allows users to define filtering rules in human-readable text, and ``libbpfilter``, a library that converts these rules into efficient BPF programs and manages their lifecycle.
 
 Want to know more about **bpfilter**? Check the :doc:`user's guide <usage/index>`, the :doc:`developer documentation <developers/build>`, or watch our talk at `Scale <https://www.youtube.com/watch?v=fzaPEm4PXn0>`_!

doc/usage/bfcli.rst

@@ -1,7 +1,20 @@
 ``bfcli``
 =========
 
-``bfcli`` is a command line tool to communicate with the bpfilter daemon.
+``bfcli`` is the command line tool for defining and managing bpfilter filtering rules. It calls ``libbpfilter`` directly to generate, load, and manage BPF programs.
+
+Environment variables
+---------------------
+
+``bfcli`` reads the following environment variables to configure the library before processing commands. These variables are ignored when ``--dry-run`` is used.
+
+- ``BF_BPFFS_PATH``: path to the BPF filesystem directory. Defaults to ``/sys/fs/bpf``. bpfilter pins BPF objects under a ``bpfilter`` subdirectory at this path.
+- ``BF_WITH_BPF_TOKEN``: if set (any value), associate a BPF token to every ``bpf()`` system call. Required when running in user namespaces. The token is created from the bpffs at ``BF_BPFFS_PATH``. Only supported for kernel v6.9+.
+- ``BF_VERBOSE``: comma-separated list of verbose flags. Supported values:
+
+  - ``debug``: enable debug logs.
+  - ``bpf``: insert log messages into BPF programs to log failed kernel function calls. View with ``bpftool prog tracelog`` or ``cat /sys/kernel/debug/tracing/trace_pipe``.
+  - ``bytecode``: dump a program's bytecode before loading it.
 
 Commands
 --------
@@ -32,7 +45,7 @@ Chains with valid hook options defined are attached to their hook. Chains withou
 ``ruleset get``
 ~~~~~~~~~~~~~~~
 
-Print the ruleset: request all the chains and rules from the daemon with counters values.
+Print the ruleset: request all the chains and rules with counters values.
 
 **Example**
 
@@ -49,7 +62,7 @@ Print the ruleset: request all the chains and rules from the daemon with counter
 ``ruleset flush``
 ~~~~~~~~~~~~~~~~~
 
-Remove all the chains and rules defined by the daemon. Once this command completes, the daemon doesn't contain any filtering rules, as if it was freshly started.
+Remove all the chains and rules. Once this command completes, bpfilter doesn't contain any filtering rules.
 
 **Examples**
 
@@ -69,14 +82,14 @@ Remove all the chains and rules defined by the daemon. Once this command complet
 ``chain set``
 ~~~~~~~~~~~~~
 
-Generate and load a chain into the kernel. If the chain definition contains hook options, the daemon will attach it to its hook. Any existing chain with the same name (attached or not) will be discarded and replaced with the new one.
+Generate and load a chain into the kernel. If the chain definition contains hook options, bpfilter will attach it to its hook. Any existing chain with the same name (attached or not) will be discarded and replaced with the new one.
 
 If you want to update an existing chain without downtime, use ``bfcli chain update`` instead.
 
 **Options**
   - ``--from-str CHAIN``: read the chain to set from the command line arguments.
   - ``--from-file FILEPATH``: read the chain from a file.
-  - ``--name NAME``: if ``--from-str`` or ``--from-file`` provide multiple chains, ``NAME`` specify which one to send to the daemon.
+  - ``--name NAME``: if ``--from-str`` or ``--from-file`` provide multiple chains, ``NAME`` specifies which one to use.
   - ``--dry-run``: parse and validate the chain, but do not apply it.
 
 **Examples**
@@ -158,7 +171,7 @@ If a chain with the same name already exist, it won't be replaced. See ``bfcli c
 **Options**
   - ``--from-str CHAIN``: read the chain to set from the command line arguments.
   - ``--from-file FILEPATH``: read the chain from a file.
-  - ``--name NAME``: if ``--from-str`` or ``--from-file`` provide multiple chains, ``NAME`` specify which one to send to the daemon.
+  - ``--name NAME``: if ``--from-str`` or ``--from-file`` provide multiple chains, ``NAME`` specifies which one to use.
   - ``--dry-run``: parse and validate the chain, but do not apply it.
 
 **Examples**
@@ -213,7 +226,7 @@ If you want to modify the hook options, use ``bfcli chain set`` instead.
 **Options**
   - ``--from-str CHAIN``: read the chain to set from the command line arguments.
   - ``--from-file FILEPATH``: read the chain from a file.
-  - ``--name NAME``: if ``--from-str`` or ``--from-file`` provide multiple chains, ``NAME`` specify which one to send to the daemon.
+  - ``--name NAME``: if ``--from-str`` or ``--from-file`` provide multiple chains, ``NAME`` specifies which one to use.
   - ``--dry-run``: parse and validate the chain, but do not apply it.
 
 **Examples**

doc/usage/index.rst

@@ -6,15 +6,12 @@ Usage
    :maxdepth: 2
    :caption: Usage
 
-   daemon
    bfcli
 
 
-``bpfilter`` is composed of two main parts that work together: the client used by the users to define the filtering rules and send them to the **daemon** that performs the heavy lifting of generating the BPF bytecode.
+``bpfilter`` is composed of two main parts: ``libbpfilter``, the core library that generates and manages BPF programs, and ``bfcli``, the CLI used to define filtering rules. ``bfcli`` calls ``libbpfilter`` directly to translate rules into BPF programs and load them into the kernel.
 
-Before anything, you will have to run the daemon on your system, see :doc:`daemon` for more details.
-
-Then, use ``bfcli`` to create, update, or read chains.
+See :doc:`bfcli` for the full command reference and filter syntax.
 
 Install
 -------
@@ -31,7 +28,7 @@ If you use a different distribution, you can still build and use **bpfilter** if
 Example usage
 -------------
 
-From here on, we assume **bpfilter** has been installed on your system. If you build it locally, you will need to substitute the ``bpfilter`` command with ``$BUILD_DIR/output/sbin/bpfilter``, same for ``bfcli``. The example below is meant to familiarize you with **bpfilter**, more in-depth information can be found throughout the documentation.
+From here on, we assume **bpfilter** has been installed on your system. If you build it locally, you will need to substitute the ``bfcli`` command with ``$BUILD_DIR/output/bin/bfcli``. The example below is meant to familiarize you with **bpfilter**, more in-depth information can be found throughout the documentation.
 
 This example will block ``ping`` requests sent going out of the local host to a remote server.
 
@@ -53,19 +50,9 @@ Let's check if we can ping ``facebook.com`` before we do anything:
 	rtt min/avg/max/mdev = 23.596/25.493/28.622/1.880 ms
 
 
-**Start the daemon**
-
-The daemon is responsible for receiving the user-defined filtering rules, and translating them into BPF programs. We will start it in ``--transient`` mode, so all the filtering programs defined will be discarded when we stop it, preventing any mistake on our side!
-
-.. code-block:: bash
-
-	$ sudo bpfilter --transient
-	info   : waiting for requests...
-
-
 **Create a new filtering rule**
 
-Now that the daemon is up and running, we will use ``bfcli`` to send a filtering chain. A chain is a set of rules to filter packets on:
+Use ``bfcli`` to create a filtering chain. A chain is a set of rules to filter packets on:
 
 .. code-block:: bash