X-Git-Url: http://git.onelab.eu/?a=blobdiff_plain;f=include%2Fopenvswitch%2Ftypes.h;h=d9a5dc88353edbd50340b5d11b66e616a697d5f7;hb=HEAD;hp=fbd2997b32b0c1afc9f262cd841caf985eb38e4f;hpb=d8ae4d672673cd72285eb405a96b4ac3590a7639;p=sliver-openvswitch.git

diff --git a/include/openvswitch/types.h b/include/openvswitch/types.h
index fbd2997b3..d9a5dc883 100644
--- a/include/openvswitch/types.h
+++ b/include/openvswitch/types.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2010 Nicira Networks.
+ * Copyright (c) 2010, 2011, 2013 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -17,6 +17,8 @@
 #ifndef OPENVSWITCH_TYPES_H
 #define OPENVSWITCH_TYPES_H 1
 
+#include <linux/types.h>
+#include <sys/types.h>
 #include <stdint.h>
 
 #ifdef __CHECKER__
@@ -30,10 +32,76 @@
 /* The ovs_be<N> types indicate that an object is in big-endian, not
  * native-endian, byte order.  They are otherwise equivalent to uint<N>_t.
  *
- * The OVS_BITWISE annotation allows the sparse checker to issue warnings
- * for incorrect use of values in network byte order. */
-typedef uint16_t OVS_BITWISE ovs_be16;
-typedef uint32_t OVS_BITWISE ovs_be32;
-typedef uint64_t OVS_BITWISE ovs_be64;
+ * We bootstrap these from the Linux __be<N> types.  If we instead define our
+ * own independently then __be<N> and ovs_be<N> become mutually
+ * incompatible. */
+typedef __be16 ovs_be16;
+typedef __be32 ovs_be32;
+typedef __be64 ovs_be64;
+
+#define OVS_BE16_MAX ((OVS_FORCE ovs_be16) 0xffff)
+#define OVS_BE32_MAX ((OVS_FORCE ovs_be32) 0xffffffff)
+#define OVS_BE64_MAX ((OVS_FORCE ovs_be64) 0xffffffffffffffffULL)
+
+/* These types help with a few funny situations:
+ *
+ *   - The Ethernet header is 14 bytes long, which misaligns everything after
+ *     that.  One can put 2 "shim" bytes before the Ethernet header, but this
+ *     helps only if there is exactly one Ethernet header.  If there are two,
+ *     as with GRE and VXLAN (and if the inner header doesn't use this
+ *     trick--GRE and VXLAN don't) then you have the choice of aligning the
+ *     inner data or the outer data.  So it seems better to treat 32-bit fields
+ *     in protocol headers as aligned only on 16-bit boundaries.
+ *
+ *   - ARP headers contain misaligned 32-bit fields.
+ *
+ *   - Netlink and OpenFlow contain 64-bit values that are only guaranteed to
+ *     be aligned on 32-bit boundaries.
+ *
+ * lib/unaligned.h has helper functions for accessing these. */
+
+/* A 32-bit value, in host byte order, that is only aligned on a 16-bit
+ * boundary.  */
+typedef struct {
+#ifdef WORDS_BIGENDIAN
+        uint16_t hi, lo;
+#else
+        uint16_t lo, hi;
+#endif
+} ovs_16aligned_u32;
+
+/* A 32-bit value, in network byte order, that is only aligned on a 16-bit
+ * boundary. */
+typedef struct {
+        ovs_be16 hi, lo;
+} ovs_16aligned_be32;
+
+/* A 64-bit value, in host byte order, that is only aligned on a 32-bit
+ * boundary.  */
+typedef struct {
+#ifdef WORDS_BIGENDIAN
+        uint32_t hi, lo;
+#else
+        uint32_t lo, hi;
+#endif
+} ovs_32aligned_u64;
+
+/* A 64-bit value, in network byte order, that is only aligned on a 32-bit
+ * boundary. */
+typedef struct {
+        ovs_be32 hi, lo;
+} ovs_32aligned_be64;
+
+/* ofp_port_t represents the port number of a OpenFlow switch.
+ * odp_port_t represents the port number on the datapath.
+ * ofp11_port_t represents the OpenFlow-1.1 port number. */
+typedef uint16_t OVS_BITWISE ofp_port_t;
+typedef uint32_t OVS_BITWISE odp_port_t;
+typedef uint32_t OVS_BITWISE ofp11_port_t;
+
+/* Macro functions that cast int types to ofp/odp/ofp11 types. */
+#define OFP_PORT_C(X) ((OVS_FORCE ofp_port_t) (X))
+#define ODP_PORT_C(X) ((OVS_FORCE odp_port_t) (X))
+#define OFP11_PORT_C(X) ((OVS_FORCE ofp11_port_t) (X))
 
 #endif /* openvswitch/types.h */