So far, during this discussion, it was proposed to modify the file systemThis would probably work as you would typically map the ebpf map
>to a single-mount one and to stick this under/sys/kernel/bpf/. This
>will not have "real" namespace support either, but it was proposed to
>have a following structure:
>
> /sys/kernel/bpf/username/<optional_dirs_mkdir_by_user>/progX
using -v like this to give a stable path:
docker run -v /sys/kernel/bpf/foo/maps/progX:/map proX
>Together with device cgroups for containers, it would allow scenarios where
>you can have:
>
> * eBPF (map/prog) device pass-through so a map/prog could even be shared out
> from the initial namespace into individual ones/all (one could possibly
> extend such maps as read-only for these consumers).
> * eBPF device creation for unprivileged users with permissions being set
> accordingly (as in fs case).
> * Since cgroup controller can also do wildcards on major/minors, we could
> make that further fine-grained.
> * eBPF device creation can also be enforced by the cgroup controller to be
> entirely disallowed for a specific container.
I've read the discussion passively and my take away is that, frankly,
I think the differences are somewhat minor. Both architectures can
scale to what we need. Both will do the job. I'm slightly worried about
exposing uAPI as a FS, I think that didn't work too well for sysfs. It's
pretty much a define the format once and never touch it again kind of
deal.