On Mon, Oct 07, 2019 at 05:43:44PM +0100, Edward Cree wrote: > > (Although I also think full-blown dynamically-linked calls ought not to be > impossible, *if* we restrict them to taking a ctx and returning a u64, in > which case the callee can be verified as though it were a normal program, > and the caller's verifier just treats the program as returning an unknown > scalar. The devil is in the details, though, and it seems no-one's quite > wanted it enough to do the work required to make it happen.) Absolutely. Full dynamic linking and libraries is on todo list. It's taking long time, since it needs to be powerful and generic from the day one. If we do 'pass ctx only and return u64' as a stop gap, it will be just as limited as existing bpf_tail_calls. bpf_tail_call api was badly designed. I couldn't figure out how to make tail calls safe and generic, so I came up with this bpf_tail_call hack. bpf usability suffers. The verifier is different now. It's powerful enough to do true calls and jumps. Especially with BTF it can see and track all types. True tail calls will be seen as indirect jump assembler insn. True indirect calls will be seen as indirect call assembler insn. The choice of opcode encoding is clear. The verifier, interpreter, and JIT work left. It won't take long.
