Hi Mathieu,

I attached an updated series.

I think I fixed up the lint errors. Pardon me.

>> +(define-public libbpf
>> +  (let* ((commit "6a1615c263b679c17ecb292fa897f159e826dc10"))

> Why using a specific commit?

> The "0.0.9" is out there :)

I updated the packages where it was appropriate. bcc also had an
available update, oops.

>> +      (source
>> +       (origin
>> +         (method git-fetch)
>> +         (uri (git-reference
>> +               (url "https://github.com/libbpf/libbpf")
>> +               (commit commit)))
> 
> (commit (string-append "v" version)) should work fine.

> +         ("pkg-config" ,pkg-config)

> This should be a native-input, don't forget to run the linter :)

Done, also I made flex and bison native inputs where appropriate.

>> +          (string-append "PREFIX=''")
>> +          (string-append "DESTDIR=" (assoc-ref %outputs "out"))
>> +          (string-append
>> +           "CC=" (assoc-ref %build-inputs "gcc") "/bin/gcc"))
> 
> This will put libraries in "lib64" directory which is not desired. You
> can set LIBDIR to "/lib" to avoid that.

Done, thank you.

>> +               (chdir "src")
> 
> I'm not sure this is needed.

I tried without and it failed. I looked at the libbpf build guide and it
says to cd src.  I wish I could remove it, too.

>> +               #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.")
> 
> "kernel-devel" is more Debian specific I think. I'm also not sure that
> the "Clang deploying" things applied well to Guix.

I think I tidied up the description to match the Guix situation. What do
you think now?

>> +(define-public linux-libre-with-bpf
>> +  (make-linux-libre* linux-libre-5.4-version
>> +                     linux-libre-5.4-source
>> + '("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux"
>> "riscv64-linux")
>> +                     #:extra-version "bpf"
>> +                     #:configuration-file kernel-config
>> +                     #:extra-options
>> +                     (append %bpf-extra-linux-options
>> +                             %default-extra-linux-options)))
>> +
>
> What would be the drawbacks of enabling BPF in the default linux-libre
> kernel?

I could see it being a useful default.  BPF seems like a nice technology
but I am making these patches to experiment with it myself.  Because I
haven't used it much I can't really speak on the pros of making it
default.  Other than my gut feeling that seems like something that
should be opted into rather than opting out of I have no strong feelings
on including it by default.  The only other downside I see is that
putting in the default might make the linux definitions less composable.
The way it is now, one can assemble a (mostly) bpf-capable system from
the pieces in gnu/packages/linux.scm.

That said, I think there are a few more missing pieces to get full
functionality. Running the example bpftrace scripts gives errors like
this:

open(/sys/kernel/debug/tracing/uprobe_events): No such file or directory

I think that means the operating system definition might need to specify
more file systems but I can't seem to work out which ones are required
and where to specify them.  My first guess is that it would need to be
debugfs and mounted in initramfs?  I am not sure.

Thanks for your feedback!

- John