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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to