[ovs-dev] [PATCH] datapath: Add support for kernel 3.14.
Thomas Graf
tgraf at redhat.com
Tue Apr 8 15:54:32 UTC 2014
On 04/07/2014 07:54 PM, Pritesh Kothari wrote:
> diff --git a/datapath/linux/compat/include/linux/etherdevice.h b/datapath/linux/compat/include/linux/etherdevice.h
> index 556729d..88f8ee3 100644
> --- a/datapath/linux/compat/include/linux/etherdevice.h
> +++ b/datapath/linux/compat/include/linux/etherdevice.h
> @@ -34,6 +34,7 @@ static inline int eth_mac_addr(struct net_device *dev, void *p)
> }
> #endif
>
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(3,14,0)
> static inline void ether_addr_copy(u8 *dst, const u8 *src)
> {
> #if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
> @@ -48,5 +49,6 @@ static inline void ether_addr_copy(u8 *dst, const u8 *src)
> a[2] = b[2];
> #endif
> }
> +#endif
This will break with upcoming RHEL releases. I bet other distributions
will backport this too. Can we convert this to use:
OVS_GREP_IFELSE([$KSRC/include/linux/etherdevice.h], [ether_addr_copy])
to avoid compat issues down the road?
> #endif
> diff --git a/datapath/linux/compat/include/linux/net.h b/datapath/linux/compat/include/linux/net.h
> index d8bf621..367e8b6 100644
> --- a/datapath/linux/compat/include/linux/net.h
> +++ b/datapath/linux/compat/include/linux/net.h
> @@ -51,4 +51,8 @@ bool __net_get_random_once(void *buf, int nbytes, bool *done,
> })
> #endif
>
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(3,8,0)
> +#define prandom_u32() random32()
> +#endif
Same here
> #endif
> diff --git a/datapath/linux/compat/include/linux/skbuff.h b/datapath/linux/compat/include/linux/skbuff.h
> index de0c56a..812ed00 100644
> --- a/datapath/linux/compat/include/linux/skbuff.h
> +++ b/datapath/linux/compat/include/linux/skbuff.h
> @@ -262,6 +262,7 @@ static inline __u32 skb_get_rxhash(struct sk_buff *skb)
> unsigned int skb_zerocopy_headlen(const struct sk_buff *from);
> void skb_zerocopy(struct sk_buff *to, const struct sk_buff *from, int len,
> int hlen);
> +#define skb_get_hash skb_get_rxhash
and here
As distributions continue to maintain their own kernel, relying on the
vanilla kernel release number is somewhat fragile. I realize it's more
effort to check for definitions but it will produce more reliable code.
More information about the dev
mailing list