Do that instead of just not defining the BPF stuff if __LINUX_FILTER_H__
is defined. That way, our definitions override the <linux/filter.h>
definitions. If those differ from our definitions, we want our
definitions, at least when building the BPF code generator, so that, for
example, we support the modulo and XOR operators. (If the kernel
doesn't support them, the attempt to set the kernel filter will fail if
we use BPF_MOD or BPF_XOR, and we'll fall back on doing userland
filtering.)
This should address GitHub issue #987.
(cherry picked from commit
2abff2bc2dbd2be3888330e9ce0df298dd441d8a)
-#ifndef __LINUX_FILTER_H__
-
/*
* The instruction encodings.
*
/*
* The instruction encodings.
*
/* 0xf0 reserved */
/* 0xf8 reserved */
/* 0xf0 reserved */
/* 0xf8 reserved */
-#endif /* __LINUX_FILTER_H__ */
-
/*
* The instruction data structure.
*/
/*
* The instruction data structure.
*/
-#ifndef __LINUX_FILTER_H__
-
/*
* Macros for insn array initializers.
/*
* Macros for insn array initializers.
+ *
+ * In case somebody's included <linux/filter.h>, or something else that
+ * gives the kernel's definitions of BPF statements, get rid of its
+ * definitions, so we can supply ours instead. If some kernel's
+ * definitions aren't *binary-compatible* with what BPF has had
+ * since it first sprung from the brows of Van Jacobson and Steve
+ * McCanne, that kernel should be fixed.
+#ifdef BPF_STMT
+#undef BPF_STMT
+#endif
#define BPF_STMT(code, k) { (u_short)(code), 0, 0, k }
#define BPF_STMT(code, k) { (u_short)(code), 0, 0, k }
+#ifdef BPF_JUMP
+#undef BPF_JUMP
+#endif
#define BPF_JUMP(code, k, jt, jf) { (u_short)(code), jt, jf, k }
#define BPF_JUMP(code, k, jt, jf) { (u_short)(code), jt, jf, k }
-#endif /* __LINUX_FILTER_H__ */
-
PCAP_AVAILABLE_0_4
PCAP_API u_int bpf_filter(const struct bpf_insn *, const u_char *, u_int, u_int);
PCAP_AVAILABLE_0_4
PCAP_API u_int bpf_filter(const struct bpf_insn *, const u_char *, u_int, u_int);