Subject: Re: Edited draft of bpf(2) man page for review/enhancement
To: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
References: <556583B4.4000607@gmail.com> <55669E44.6050907@plumgrid.com>
 <55AFAE47.70209@gmail.com>
Cc: Silvan Jegen <s.jegen@gmail.com>, linux-man@vger.kernel.org,
        linux-kernel@vger.kernel.org, Daniel Borkmann <daniel@iogearbox.net>,
        Walter Harms <wharms@bfs.de>
From: Alexei Starovoitov <ast@plumgrid.com>
Message-ID: <55AFD64E.9040105@plumgrid.com>
Date: Wed, 22 Jul 2015 10:43:42 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <55AFAE47.70209@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3000
Lines: 89

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/