0

I've seen that instead of using #include <stddef.h> to have access to offsetof macro, ebpf programs conditionally define the macro inside the prog_kern.c file. Is it wrong to include stddef.h in prog_kern.c? If yes, why should I avoid it?

Maicake
  • 1,046
  • 10
  • 34
  • 1
    I do not know. Maybe try with and without including `stddef.h` (or reimplementing the macro), compile your program and see if there is any difference in the BPF code produced? (`llvm-objdump -d mine_kern.o`) – Qeole Aug 17 '19 at 12:56
  • Implementing the macro require size_t that also is defined in . Anyway I'm still not sure if I should include libc headers or not in the kernel part of the code. – Maicake Aug 22 '19 at 08:11
  • 1
    Including headers is not an issue per se. What is not possible is calling (most of) the functions usually available from the standard headers, because once your program is loaded in the kernel, those functions are no longer accessible and it would not make sense to call them. A few number are sometimes inlined by the compiler (e.g. `memcpy()`). As a macro, `offsetof` should work as well. But if you need type or macros, there's nothing wrong with including headers. Network processing programs often include headers to get e.g. struct definitions / protocol numbers for L2/L3/L4 packet headers. – Qeole Aug 22 '19 at 08:51
  • https://github.com/torvalds/linux/blob/6f0d349d922ba44e4348a17a78ea51b7135965b1/samples/bpf/sockex3_kern.c in this example offsetof is used but I can't see stddef.h – Maicake Aug 22 '19 at 09:23
  • 1
    `#include `#include ` -> `#include ` -> `#include ` – Qeole Aug 22 '19 at 09:43

0 Answers0