Jakub Kicinski <jakub.kicinski@xxxxxxxxxxxxx> writes: > On Fri, 04 Oct 2019 19:22:42 +0200, Toke Høiland-Jørgensen wrote: >> From: Alan Maguire <alan.maguire@xxxxxxxxxx> >> >> This adds support for setting and deleting bpf chain call programs through >> a couple of new commands in the bpf() syscall. The CHAIN_ADD and CHAIN_DEL >> commands take two eBPF program fds and a return code, and install the >> 'next' program to be chain called after the 'prev' program if that program >> returns 'retcode'. A retcode of -1 means "wildcard", so that the program >> will be executed regardless of the previous program's return code. >> >> >> The syscall command names are based on Alexei's prog_chain example[0], >> which Alan helpfully rebased on current bpf-next. However, the logic and >> program storage is obviously adapted to the execution logic in the previous >> commit. >> >> [0] https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?h=prog_chain&id=f54f45d00f91e083f6aec2abe35b6f0be52ae85b&context=15 >> >> Signed-off-by: Alan Maguire <alan.maguire@xxxxxxxxxx> >> Signed-off-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx> > > It'd be good to explain why not just allocate a full prog array (or > in fact get one from the user), instead of having a hidden one which > requires new command to interact with? Because I consider the reuse of the prog array to be an implementation detail that we may want to change later. Whereas if we expose it to userspace it becomes API. For instance, if we do end up wanting to have support directly in the JIT for this, we could make the next progs just a linked list that the JIT will walk and emit direct call instructions for each, instead of doing the index-lookup. -Toke
