Re: BPF in linux-libre

[John Soo]

Hi Mathieu,

Mathieu Othacehe <othacehe@gnu.org> writes:

> Now, it's just a matter of packaging "bcc" and "bpftrace" I guess.

I was working on these yesterday. I keep getting errors that seem to
indicate the linux-libre-headers we have might not be compatible:

Here's my definition:

(define-public bcc
  (let* ((ver "0.14.0")
         (commit (string-append "v" ver)))
    (package
      (name "bcc")
      (version ver)
      (source
       (origin
         (method git-fetch)
         (uri (git-reference
               (url "https://github.com/iovisor/bcc";)
               (commit commit)))
         (file-name (git-file-name name ver))
         (sha256
          (base32
           "08m21avzamr48qwshd4r5hlcckk1kvgrb1i6qw373b7la89jf5an"))))
      (build-system cmake-build-system)
      (inputs
       `(("bison" ,bison)
         ("clang-toolchain" ,clang-toolchain)
         ("flex" ,flex)
         ("libbpf" ,libbpf)
         ("libelf" ,libelf)
         ("linux-libre-headers" ,linux-libre-headers)
         ("python-wrapper" ,python-wrapper)))
      (arguments
       `(#:parallel-build? #f
         #:configure-flags
         (list
          (string-append
           "-DLIBBPF_INCLUDE_DIR=" (assoc-ref %build-inputs "libbpf") 
"/include"))))
      (home-page "https://github.com/iovisor/bcc";)
      (synopsis "Tools for BPF on Linux")
      (description
       "BCC is a toolkit for creating efficient kernel tracing and
manipulation programs, and includes several useful tools and examples.  It
makes use of extended BPF (Berkeley Packet Filters), formally known as eBPF, a
new feature that was first added to Linux 3.15.  Much of what BCC uses requires
Linux 4.1 and above.")
      (license license:asl2.0))))

I get a lot of errors that certain things are undefined.  I am guessing
the names should be available in the linux headers?

/tmp/guix-build-bcc-0.14.0.drv-0/source/src/cc/libbpf.c:694:58: error: 
‘BPF_PROG_TYPE_EXT’ undeclared (first use in this function); did you mean 
‘BPF_PROG_TYPE_XDP’?
   if (prog_type != BPF_PROG_TYPE_TRACING && prog_type != BPF_PROG_TYPE_EXT)
                                                          ^~~~~~~~~~~~~~~~~
                                                          BPF_PROG_TYPE_XDP

The bcc github releases seem to indicate that bcc supports kernels up to
5.6.

I also defined libbpf (included as a submodule) like this:

(define-public libbpf
  (let* ((commit "6a1615c263b679c17ecb292fa897f159e826dc10"))
    (package
      (name "libbpf")
      (version "0.0.8")
      (source
       (origin
         (method git-fetch)
         (uri (git-reference
               (url "https://github.com/libbpf/libbpf";)
               (commit commit)))
         (sha256
          (base32
           "02vbpg9v5sjcw7ihximy63cjmz82q5izkp91i44m1qp6qj5qn4sr"))))
      (build-system gnu-build-system)
      (inputs
       `(("libelf" ,libelf)
         ("pkg-config" ,pkg-config)
         ("zlib" ,zlib)))
      (arguments
       `(#:tests? #f ; No tests
         #:make-flags
         (list
          (string-append "PREFIX=''")
          (string-append "DESTDIR=" (assoc-ref %outputs "out"))
          (string-append
           "CC=" (assoc-ref %build-inputs "gcc") "/bin/gcc"))
         #:phases
         (modify-phases %standard-phases
           (delete 'configure)
           (add-before 'build 'pre-build
             (lambda* (#:key inputs #:allow-other-keys)
               (substitute* "scripts/check-reallocarray.sh"
                 (("/bin/rm" rm)
                  (string-append (assoc-ref inputs "coreutils") rm)))
               (chdir "src")
               #t)))))
      (home-page "https://github.com/libbpf/libbpf";)
      (synopsis "BPF CO-RE (Compile Once – Run Everywhere)")
      (description
       "Libbpf supports building BPF CO-RE-enabled applications, which, in
contrast to BCC, do not require Clang/LLVM runtime being deployed to target
servers and does not rely on kernel-devel headers being available.")
      (license `(,license:lgpl2.1 ,license:bsd-2)))))

I'm not sure where to go from here.

Thanks for the help!

- John