From: Daniel Borkmann <dborkman@redhat.com>
To: Alexei Starovoitov <ast@plumgrid.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Ingo Molnar <mingo@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andy Lutomirski <luto@amacapital.net>,
Steven Rostedt <rostedt@goodmis.org>,
Chema Gonzalez <chema@google.com>,
Eric Dumazet <edumazet@google.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Brendan Gregg <brendan.d.gregg@gmail.com>,
Namhyung Kim <namhyung@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
linux-api@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 net-next 2/2] net: filter: split filter.h and expose eBPF to user space
Date: Fri, 29 Aug 2014 19:39:03 +0200 [thread overview]
Message-ID: <5400BAB7.80001@redhat.com> (raw)
In-Reply-To: <1409171833-6979-3-git-send-email-ast@plumgrid.com>
On 08/27/2014 10:37 PM, Alexei Starovoitov wrote:
> allow user space to generate eBPF programs
>
> uapi/linux/bpf.h: eBPF instruction set definition
>
> linux/filter.h: the rest
Very sorry for being late, but just a thought since we're touching user
space headers anyway ...
Wouldn't it be more consistent to have it organized as follows ...
- uapi/linux/bpf.h : classic BPF instruction set parts only
- uapi/linux/ebpf.h : eBPF instruction set definition (which also
includes uapi/linux/bpf.h though)
... and have ...
- uapi/linux/filter.h : just include uapi/linux/bpf.h but rest is empty
That way, it would be more consistent ...
Old legacy application can stay with linux/filter.h; new applications
based on their needs can choose between linux/{e,}bpf.h and in the kernel,
we can just include linux/ebpf.h.
Right now, it seems, an eBPF user space program would need to include
2 header files in user space (linux/filter.h, linux/bpf.h) which I find
a bit confusing.
If you want, I could also take care of that later, but just thinking out
loudly ...
> This patch only moves macro definitions, but practically it freezes existing
> eBPF instruction set, though new instructions can still be added in the future.
>
> These eBPF definitions cannot go into uapi/linux/filter.h, since the names
> may conflict with existing applications.
>
> Full eBPF ISA description is in Documentation/networking/filter.txt
>
> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
next prev parent reply other threads:[~2014-08-29 17:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-27 20:37 [PATCH v8 net-next 0/2] load imm64 insn and uapi/linux/bpf.h Alexei Starovoitov
2014-08-27 20:37 ` [PATCH v8 net-next 1/2] net: filter: add "load 64-bit immediate" eBPF instruction Alexei Starovoitov
[not found] ` <1409171833-6979-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
2014-08-27 20:37 ` [PATCH v8 net-next 2/2] net: filter: split filter.h and expose eBPF to user space Alexei Starovoitov
2014-08-27 20:37 ` Alexei Starovoitov
2014-08-29 17:39 ` Daniel Borkmann [this message]
[not found] ` <5400BAB7.80001-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-08-29 18:02 ` Alexei Starovoitov
2014-08-29 18:02 ` Alexei Starovoitov
[not found] ` <CAADnVQJbgiUK1vt_SDEG6Yee-Ht67e2M82PrHb3Kx533BOF-rg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-08-29 22:24 ` Daniel Borkmann
2014-08-29 22:24 ` Daniel Borkmann
[not found] ` <5400FDA0.7000704-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-08-29 23:01 ` Alexei Starovoitov
2014-08-29 23:01 ` Alexei Starovoitov
2014-08-30 6:22 ` Daniel Borkmann
[not found] ` <CAMEtUuyRUujYhRsH9aUx0h7wvU1DrKRHNWZtoOYEgHVfKdCTxw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-08-30 7:48 ` Daniel Borkmann
2014-08-30 7:48 ` Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5400BAB7.80001@redhat.com \
--to=dborkman@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=ast@plumgrid.com \
--cc=brendan.d.gregg@gmail.com \
--cc=chema@google.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.