unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: John Soo <jsoo1@asu.edu>
To: Mathieu Othacehe <othacehe@gnu.org>
Cc: Help Guix <help-guix@gnu.org>
Subject: Re: BPF in linux-libre
Date: Sun, 14 Jun 2020 08:11:39 -0700	[thread overview]
Message-ID: <87h7vdd6ms.fsf@asu.edu> (raw)
In-Reply-To: <87lfkqknla.fsf@gnu.org> (Mathieu Othacehe's message of "Sun, 14 Jun 2020 11:23:29 +0200")

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


  reply	other threads:[~2020-06-14 15:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-14  3:21 BPF in linux-libre John Soo
2020-06-14  9:23 ` Mathieu Othacehe
2020-06-14 15:11   ` John Soo [this message]
2020-06-17 10:16     ` Mathieu Othacehe
2020-06-17 13:42       ` John Soo
2020-06-21 15:32       ` John Soo
2020-06-26 10:50         ` Mathieu Othacehe
2020-06-28 20:24           ` John Soo
2020-07-01  5:40           ` John Soo
2020-07-03 16:01           ` John Soo
2020-07-05  8:18             ` Mathieu Othacehe
2020-07-05  8:20             ` Mathieu Othacehe
2020-07-06  0:44               ` John Soo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h7vdd6ms.fsf@asu.edu \
    --to=jsoo1@asu.edu \
    --cc=help-guix@gnu.org \
    --cc=othacehe@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).