LWN: Comments on "Extending extended BPF"

Extending extended BPF

elanthis — Thu, 10 Jul 2014 06:03:35 +0000

> int bpf(BPF_PROG_LOAD, int prog_id, enum bpf_prog_type type, struct nlattr *prog, int len);

I'd have thought kernel devs would have learned by now and have always, always, always included an `int flags` field in any new syscall, just to avoid the otherwise eventual need for `bpf2`. Unless the `nlattr` data is expected to be sufficient?

Extending extended BPF

MrWim — Thu, 03 Jul 2014 12:57:37 +0000

I wonder if it would be possible to address bpf by fd rather than by integer id. This would help clearing up filters when they are no longer in use. This would probably make namespacing easier. They could be passed around using socket passing. You could see what filters a process were using by inspecting proc/#####/fd. Also, if creating bpf programs were to continue to be a privaleged operation then you could have a bpf providing daemon running as root doing additional sanitization before uploading to the kernel and passing the fd over a Unix domain socket or DBus.

Extending extended BPF

fishface60 — Thu, 03 Jul 2014 08:49:36 +0000

This sounds like a handy way to define a new system call from user-space, in terms of others exposed to eBPF.

Extending extended BPF

Cyberax — Thu, 03 Jul 2014 07:00:14 +0000

Overhead of VFS is way too large for that purpose.

Extending extended BPF

wichert — Thu, 03 Jul 2014 06:47:35 +0000

I wonder why maps are not exposed as a filesystem? That gives you naming and permission handling and removes the need for a new set of syscalls.

Extending extended BPF

josh — Thu, 03 Jul 2014 02:56:21 +0000

> There is little point in running an eBPF program on demand from user space; there is not much that it could do that couldn't be more easily accomplished directly.

Not entirely true. There have been requests in the past for various kinds of combination/batching syscalls, and eBPF would address any such needs.