From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexei Starovoitov Subject: Re: [PATCH v8 net-next 2/2] net: filter: split filter.h and expose eBPF to user space Date: Fri, 29 Aug 2014 11:02:58 -0700 Message-ID: References: <1409171833-6979-1-git-send-email-ast@plumgrid.com> <1409171833-6979-3-git-send-email-ast@plumgrid.com> <5400BAB7.80001@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <5400BAB7.80001-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Daniel Borkmann Cc: Alexei Starovoitov , "David S. Miller" , Ingo Molnar , Linus Torvalds , Andy Lutomirski , Steven Rostedt , Chema Gonzalez , Eric Dumazet , Peter Zijlstra , Brendan Gregg , Namhyung Kim , "H. Peter Anvin" , Andrew Morton , Kees Cook , Linux API , "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-api@vger.kernel.org On Fri, Aug 29, 2014 at 10:39 AM, Daniel Borkmann wrote: > 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. It's been bugging me as well, but I suspect having it the way you described won't work. Mainly because we cannot do include inside uapi/*.h, so we would need to do include inside uapi/linux/filter.h, but that will cause serious include path confusion. That was the reason I didn't simply do include inside uapi/linux/bpf.h Also I really dislike 'ebpf' name in all lower case. If we make such header file name, we would need to rename all macros and function names to EBPF_... which I find very ugly looking. I think all good abbreviations are three letters :) So I very much prefer bpf.h as a main file name. Later we can move some of old classic BPF defines into uapi/linux/bpf_common.h and then include it in both uapi/linux/bpf.h and in uapi/linux/filter.h, then the nuisance of two include files for user space will go away. Classic users will keep using linux/filter.h and new apps will include linux/bpf.h only. I think we should probably do such header optimization later and very carefully. I'm a bit afraid to touch uapi/linux/filter.h since it's used in so many user apps.