Messages in this thread | | | Date | Tue, 5 Sep 2023 10:38:02 -0600 | From | Daniel Xu <> | Subject | Re: [PATCH] uapi/netfilter: Change netfilter hook verdict code definition from macro to enum |
| |
Hi David,
On Mon, Sep 04, 2023 at 09:02:02PM +0800, David Wang wrote: > As BPF_PROG_TYPE_NETFILTER was added in 6.4, a netfilter > bpf program can attach to netfilter hooks, process package > and return verdict back to netfilter. But those verdict > codes are defined as macro, which could not be compiled > into BTF with btf.c. libbpf, and maybe other bpf tools, > would extract information from BTF and generate a > common header "vmlinux.h". With macro definition, netfilter > bpf program would have to redefine those macro again, > besides including "vmlinux.h". > > This code change netfilter hook verdict code definition to > enum, this way, make it into BTF. > > Signed-off-by: David Wang <00107082@163.com> > --- > include/uapi/linux/netfilter.h | 16 +++++++++------- > 1 file changed, 9 insertions(+), 7 deletions(-) > > diff --git a/include/uapi/linux/netfilter.h b/include/uapi/linux/netfilter.h > index 5a79ccb76701..d2f5dfab20dc 100644 > --- a/include/uapi/linux/netfilter.h > +++ b/include/uapi/linux/netfilter.h > @@ -8,13 +8,15 @@ > #include <linux/in6.h> > > /* Responses from hook functions. */ > -#define NF_DROP 0 > -#define NF_ACCEPT 1 > -#define NF_STOLEN 2 > -#define NF_QUEUE 3 > -#define NF_REPEAT 4 > -#define NF_STOP 5 /* Deprecated, for userspace nf_queue compatibility. */ > -#define NF_MAX_VERDICT NF_STOP > +enum { > + NF_DROP = 0, > + NF_ACCEPT = 1, > + NF_STOLEN = 2, > + NF_QUEUE = 3, > + NF_REPEAT = 4, > + NF_STOP = 5, /* Deprecated, for userspace nf_queue compatibility. */ > + NF_MAX_VERDICT = NF_STOP, > +};
Switching from macro to enum works for almost all use cases, but not all. If someone if #ifdefing the symbols (which is plausible) this change would break them.
I think I've seen some other networking code define both enums and macros. But it was a little ugly. Not sure if that is acceptable here or not.
[...]
Thanks, Daniel
| |