On Thu, 2016-03-24 at 23:40 +0100, Yann Ylavic wrote:
> FWIW, I find:
>
> const struct bpf_insn prog[] = {
> /* BPF_MOV64_REG(BPF_REG_6, BPF_REG_1) */
> { BPF_ALU64 | BPF_MOV | BPF_X, BPF_REG_6, BPF_REG_1, 0, 0 },
> /* BPF_LD_ABS(BPF_W, 0) R0 = (uint32_t)skb[0] */
> { BPF_LD | BPF_ABS | BPF_W, 0, 0, 0, 0 },
> /* BPF_ALU64_IMM(BPF_MOD, BPF_REG_0, mod) */
> { BPF_ALU64 | BPF_MOD | BPF_K, BPF_REG_0, 0, 0, mod },
> /* BPF_EXIT_INSN() */
> { BPF_JMP | BPF_EXIT, 0, 0, 0, 0 }
> };
> (and all the way to make it run)
>
> something quite unintuitive from a web server developper perspective,
> simply to make SO_REUSEPORT work with forked TCP listeners (probably
> as it should out of the box)...
That is why EBPF has LLVM backend.
Basically you can write your "BPF" program in C, and let llvm convert it
into EBPF.
Sure, you still can write BPF manually, as you could write HTTPS server
in assembly.
