Re: Edited draft of bpf(2) man page for review/enhancement

[Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>]

On 7/22/15 7:52 AM, Michael Kerrisk (man-pages) wrote:
>> As Daniel said there is no spec for this C. It's a normal C where
>> things like loops, global variables, vararg, floating point,
>> struct passing and bunch of other things are not supported.
>
> I assume we're talking about the LLVM front-end, right?

yes. clang.
There is a bpf backend for gcc, but it's bit rotting now.

> Am I correct that these kernel source files are examples of this restricted C:
>
> samples/bpf/tcbpf1_kern.c
> samples/bpf/tracex2_kern.c
> samples/bpf/tracex4_kern.c
> samples/bpf/tracex1_kern.c
> samples/bpf/tracex3_kern.c
> samples/bpf/sockex1_kern.c
> samples/bpf/sockex2_kern.c

yes.

> And samples/bpf/Makefile shows the necessary LLVM incantation
> to produce the BPF binaries, right?

yes.
Now with llvm 3.7 coming out soon it's even simpler. Just:
clang -O2 -target bpf -c file.c

> Anyway, I added the following text in NOTES:
>
>         eBPF objects (maps and programs) can  be  shared  between  pro‐
>         cesses.   For  example,  after fork(2), the child inherits file
>         descriptors referring to the same eBPF objects.   In  addition,
>         file  descriptors  referring to eBPF objects can be transferred
>         over UNIX domain sockets.  File descriptors referring  to  eBPF
>         objects  can  be  duplicated in the usual way, using dup(2) and
>         similar calls.  An eBPF object is deallocated  only  after  all
>         file descriptors referring to the object have been closed.
>
> Is the above all correct?

yes. all correct.

> This makes me curious: why was the BPF functionality not designed as
> a *set* of system calls (as per these wrappers), rather than the existing
> multiplexed call?

because new commands are much easier to add to existing syscall
instead of adding new syscall for every new command.

> [[
> If
> .I key
> is found, the operation returns zero and sets the
> .I next_key
> pointer to the key of the next element.
> ]]
>
> right?

yes.

>>>           BPF_MOV64_IMM(BPF_REG_1, 1),                /* r1 = 1 */
>>>           BPF_XADD(BPF_DW, BPF_REG_0, BPF_REG_1, 0, 0),
>>> .\" FIXME What does 'lock' in the line below mean?
>>>                                   /* lock *(u64 *) r0 += r1 */
>>
>> it means that it's 'lock xadd' equivalent.
>
> Sorry -- you've assumed I'm cleverer than I am... :-}
> I'm not wiser after that comment. What is 'lock xadd'?

I meant that it is == atomic64_add

> If you might have a chance to look at my questions above and
> let me know your thoughts, then I could further edit the page
> before sending out the next draft.

I think would be great to get some form of the man page out and
work on it incrementally. Quite a few folks have asked for it.

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html