Missing includes in sample code in documentation

[rain1]

Sample code snippet https://docs.ebpf.io/linux/program-type/BPF_PROG_TYPE_LSM/

It would be more beginner friendly if that sample had includes.

For example I have tried

#include <linux/types.h>        // Defines __u32, __u64, etc.
#include <linux/errno.h>        // Kernel error codes (EPERM, etc.)
#include <bpf/bpf_helpers.h>    // eBPF helper functions
#include <linux/lsm_hooks.h>    // LSM hooks

And I have no idea what do I still have missing.

I also have this Makefile:

KERNEL_SRC := /usr/src/linux-source-6.1
COMMON_HEADERS := /usr/src/linux-headers-$(shell uname -r | sed 's/-amd64/-common/')

# Hardcoding the path to the 'asm' directory that contains 'barrier.h'
ASM_PATH := /usr/src/linux-source-6.1/arch/x86/include/asm

# Include the architecture-specific kernel headers for x86_64 explicitly
CFLAGS := -D__KERNEL__ -D__TARGET_ARCH_x86_64 \
    -I$(KERNEL_SRC)/include \
    -I$(KERNEL_SRC)/include/uapi \
    -I$(KERNEL_SRC)/include/generated/uapi \
    -I$(COMMON_HEADERS)/include \
    -I$(KERNEL_SRC)/arch/x86/include/generated \
    -I$(ASM_PATH) \
    -I$(COMMON_HEADERS)/include/asm-generic \
    -I/usr/include/bpf

# Path for object file
all: prevent_socket.o

prevent_socket.o: prevent_socket.c
	clang $(CFLAGS) -target bpf -g -O2 -c $< -o $@

clean:
	rm -f prevent_socket.o

But it keeps saying:

/usr/src/linux-source-6.1/include/linux/list.h:11:10: fatal error: 'asm/barrier.h' file not found
#include <asm/barrier.h>

Although I have file /usr/src/linux-source-6.1/arch/x86/include/asm/barrier.h

Also it seems to me that this sample is a bit misleading. Under usage section it talks about allowing socket syscall but mprotect_audit does not seem to be sockets related when looking at it's name.

[dylandreimerink]

It would be more beginner friendly if that sample had includes.

For example I have tried. [...] And I have no idea what do I still have missing.

Right. As you observed, the code snippets in most places cannot be used as is. The reason for this is that in a lot of cases it takes more then can comfortably fit on documentation pages. The aim is mostly to give you some context or feeling for where the subject fits into a larger picture.

It is not uncommon for me to take a selftest containing a large number of cases and to discard all but one. Most of the supporting code (global variables, macros, includes) are for the bits of code I discard. It quickly becomes hard to guarantee a bit of code can compile.

This does not even include compilation command, make files, libbpf versions, kernel headers, all of which work together to make something run out of the box.

I am afraid that its simply a standard of work we cannot maintain (yet) as part of the docs project. What we can do is doing a better job of citing sources. Such that every example taken from somewhere has a link co-located which you can follow to find to original version. We should do this anyways.

At some point I would like to have a way to author examples in something similar to https://go.dev/play/ but with the capability to compile, load and run eBPF. That way we can just embed links to the full scale example in the docs, have a way to verify examples keep working, and make it easy for someone to play with it. But that is going to take some effort and time 😅