Re: [PATCH bpf-next 3/3] libbpf: Add pin option to automount BPF filesystem before pinning

Andrii Nakryiko [off-list ref] writes:

On Tue, Oct 22, 2019 at 12:04 PM Toke Høiland-Jørgensen [off-list ref] wrote:

quoted

Andrii Nakryiko [off-list ref] writes:

quoted

On Tue, Oct 22, 2019 at 9:08 AM Toke Høiland-Jørgensen [off-list ref] wrote:

quoted

From: Toke Høiland-Jørgensen <redacted>

While the current map pinning functions will check whether the pin path is
contained on a BPF filesystem, it does not offer any options to mount the
file system if it doesn't exist. Since we now have pinning options, add a
new one to automount a BPF filesystem at the pinning path if that is not

Next thing we'll be adding extra options to mount BPF FS... Can we
leave the task of auto-mounting BPF FS to tools/applications?

Well, there was a reason I put this into a separate patch: I wasn't sure
it really fit here. My reasoning is the following: If we end up with a
default auto-pinning that works really well, people are going to just
use that. And end up really confused when bpffs is not mounted. And it
seems kinda silly to make every application re-implement the same mount
check and logic.

Or to put it another way: If we agree that the reasonable default thing
is to just pin things in /sys/fs/bpf, let's make it as easy as possible
for applications to do that right.

This reminds me the setrlimit() issue, though.

Heh, yeah. I personally consider the rlimit issue one of the top
usability issues with BPF :/

And we decided that library shouldn't be manipulating global resources
on behalf of users. I think this is a similar one.

Hmm, that's a fair point, actually. I do get twitchy watching most
applications just blindly setting rlimit to unlimited before they try to
load BPF programs...

I think I'll just drop this patch for now :)

-Toke