From: Daniel Borkmann <daniel@iogearbox.net>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: alexei.starovoitov@gmail.com, netdev@vger.kernel.org
Subject: Re: [PATCH iproute2 master] bpf: provide fallback defs for __NR_bpf when not avail
Date: Thu, 15 Jun 2017 01:01:14 +0200 [thread overview]
Message-ID: <5941C03A.6010107@iogearbox.net> (raw)
In-Reply-To: <20170614155648.4cfd7a73@xeon-e3>
On 06/15/2017 12:56 AM, Stephen Hemminger wrote:
> On Thu, 15 Jun 2017 00:47:15 +0200
> Daniel Borkmann <daniel@iogearbox.net> wrote:
>
>> panji reported that he wasn't able to build iproute2's bpf library
>> due to lack of __NR_bpf in his system headers. Providing a fallback
>> definition when __NR_bpf is not available in the system lets the
>> loader compile just fine, so lets add them for majority of archs.
>>
>> Reported-by: panji <jpan@live.nl>
>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>> ---
>> lib/bpf.c | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/lib/bpf.c b/lib/bpf.c
>> index ae4d97d..e1e29cc 100644
>> --- a/lib/bpf.c
>> +++ b/lib/bpf.c
>> @@ -128,6 +128,26 @@ static inline __u64 bpf_ptr_to_u64(const void *ptr)
>> return (__u64)(unsigned long)ptr;
>> }
>>
>> +#ifndef __NR_bpf
>> +# if defined(__i386__)
>> +# define __NR_bpf 357
>> +# elif defined(__x86_64__)
>> +# define __NR_bpf 321
>> +# elif defined(__aarch64__)
>> +# define __NR_bpf 280
>> +# elif defined(__sparc__)
>> +# define __NR_bpf 349
>> +# elif defined(__arm__)
>> +# define __NR_bpf 386
>> +# elif defined(__powerpc__)
>> +# define __NR_bpf 361
>> +# elif defined(__s390__)
>> +# define __NR_bpf 351
>> +# else
>> +# error __NR_bpf not defined. Update kernel headers.
>> +# endif
>> +#endif
>> +
>> static int bpf(int cmd, union bpf_attr *attr, unsigned int size)
>> {
>> #ifdef __NR_bpf
>
> Sorry this looks like a mess. enumerating architectures in two different
> projects is likely to break in future.
It says ifndef __NR_bpf, so only used then. And the numbers are uabi,
what will break here exactly? libbpf in kernel tree is having a similar
approach by the way.
next prev parent reply other threads:[~2017-06-14 23:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-14 22:47 [PATCH iproute2 master] bpf: provide fallback defs for __NR_bpf when not avail Daniel Borkmann
2017-06-14 22:56 ` Stephen Hemminger
2017-06-14 23:01 ` Daniel Borkmann [this message]
2017-06-14 23:34 ` Stephen Hemminger
2017-06-15 12:49 ` 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=5941C03A.6010107@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=alexei.starovoitov@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.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.