Subject: bug#42227: closed (Re: [bug#42227] BPF in linux-libre)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 31 Jul 2020 11:06:02 +0000

Your bug report

#42227: BPF in linux-libre

which was filed against the guix-patches package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
42227: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=42227
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: [bug#42227] BPF in linux-libre
From: Mathieu Othacehe <[email-masked]>
To: John Soo <[email-masked]>
Cc: [email-masked]
Date: Fri, 31 Jul 2020 13:04:47 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hey,

> That seems ok. I did find a few questions about debugfs on old irc logs
> and mailing lists.  My only concern again is that I would prefer to opt
> in to such a thing.  debugfs is much simpler than the bpf kernel flags
> though, so maybe it will be ok to remove in the future.

Yeah, but I saw that Ubuntu for instance is enabling it by default, so I
guess it could help to have the same behaviour in Guix System. Added it
with: 6bb07e91e1ab9367f636a3a5e9d52a9e0772aa89.

> But I cannot see anything guix does differently that would cause it to
> fail. My only feeling is perhaps our configure flags for binutils might
> be causing the issue.
>
> As is, however, bpftrace does work even with out HAVE_BFD_DISASM and I
> even used it to debug a few processes recently.

Gave it another try and I think if we could get "binutils" to produce a
dynamic version of libbfd.a, that would make the trick. Anyway, let's
proceed without BFD support for now. Pushed bpftrace as
c55acb073248392b1387017378f36a1d378fa7c4.

Closing the serie, thank you!

Mathieu

Subject: Re: BPF in linux-libre
From: Mathieu Othacehe <[email-masked]>
To: John Soo <[email-masked]>
Cc: [email-masked]
Date: Mon, 06 Jul 2020 15:26:11 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hey John,

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

Yes it's fine, thanks for the updated serie! I pushed the first patch
and patches two and three squashed together.

> 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.

Ok, thanks for explaining. I don't have much experience with BPF
either. For now we can work with a separate linux-libre, and will see
about merging it into the default, when we'll have more perspective.

I'll take more time to review patches 4 and 5. However, while trying
some of the examples packaged by BCC, I have the following error:

--8<---------------cut here---------------start------------->8---
mathieu@meru:~/guix-master$ /gnu/store/rv51f9n1w9i92m9qsg9k3ilsy3hyhjf3-bcc-0.15.0/share/bcc/tools/execsnoop
Traceback (most recent call last):
  File "/gnu/store/rv51f9n1w9i92m9qsg9k3ilsy3hyhjf3-bcc-0.15.0/share/bcc/tools/execsnoop", line 21, in <module>
    from bcc import BPF
ModuleNotFoundError: No module named 'bcc'
--8<---------------cut here---------------end--------------->8---

I think an additional wrapping is necessary. Could you please have a
look? I'm also removing help-guix, and opening a proper guix-patches
ticket.

Thanks,

Mathieu