On 05/09/2018 11:39 PM, David Ahern wrote: > On 5/9/18 3:29 PM, David Ahern wrote: >> On 5/9/18 2:44 PM, Daniel Borkmann wrote: >>> Generally, no objection. However, could we get rid of the two extra >>> includes altogether >>> to avoid running into any such dependency issue? Right now the only >>> includes we have in >>> the bpf uapi header is linux/types.h and linux/bpf_common.h (latter has no >>> extra deps >>> by itself). Both the ETH_ALEN and struct in6_addr are in uapi and therefore >>> never allowed >>> to change so we can e.g. avoid to use ETH_ALEN and just have the value >>> instead. In the >>> other places of the header we use __u32 remote_ipv6[4], __u32 src_ip6[4] >>> etc to denote >>> a v6 address, we could do the same here and should be all good then. >> >> I was able to drop the include of linux/in6.h and still use in6_addr. I >> would prefer to keep in6_addr since it works and avoid the need to add >> typecasts. > > Never mind; that was working because if_ether.h was pulling in skbuff.h > which included in6.h. > >> As for ETH_ALEN, I could redefine it but it just kicks the can down the >> road. If if_ether.h is included after bpf.h, it will cause redefinition >> warnings. > > I guess I will continue the open coded magic numbers for mac and ipv6 > addresses.
Agree, it will avoid breakage. We cannot assume that every BPF prog out there has one specific ordering of if_ether.h and bpf.h includes. Open coding the numbers seems best here.
