Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: > On Tue, Oct 22, 2019 at 12:04 PM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes: >> >> > On Tue, Oct 22, 2019 at 9:08 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> >> >> From: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> >> >> >> >> 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
