diff options
author | Ben Pfaff <blp@ovn.org> | 2016-04-22 16:51:03 -0700 |
---|---|---|
committer | Ben Pfaff <blp@ovn.org> | 2016-05-09 16:42:56 -0700 |
commit | b70e697679bd0b8f248348be6985c996f85643ab (patch) | |
tree | bdafe95e3058fd0181f9c42910a6be500d0e3884 /include/openvswitch/compiler.h | |
parent | 790c5d2694bb3ddc3927b2e3617157ba2b19dc39 (diff) | |
download | openvswitch-b70e697679bd0b8f248348be6985c996f85643ab.tar.gz |
cmap: New macro CMAP_INITIALIZER, for initializing an empty cmap.
Sometimes code is much simpler if we can statically initialize data
structures. Until now, this has not been possible for cmap-based data
structures, so this commit introduces a CMAP_INITIALIZER macro.
This works by adding a singleton empty cmap_impl that simply forces the
first insertion into any cmap that points to it to allocate a real
cmap_impl. There could be some risk that rogue code modifies the
singleton, so for safety it is also marked 'const' to allow the linker to
put it into a read-only page.
This adds a new OVS_ALIGNED_VAR macro with GCC and MSVC implementations.
The latter is based on Microsoft webpages, so developers who know Windows
might want to scrutinize it.
As examples of the kind of simplification this can make possible, this
commit removes an initialization function from ofproto-dpif-rid.c and a
call to cmap_init() from tnl-neigh-cache.c. An upcoming commit will add
another user.
CC: Jarno Rajahalme <jarno@ovn.org>
CC: Gurucharan Shetty <guru@ovn.org>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ryan Moats <rmoats@us.ibm.com>
Diffstat (limited to 'include/openvswitch/compiler.h')
-rw-r--r-- | include/openvswitch/compiler.h | 13 |
1 files changed, 9 insertions, 4 deletions
diff --git a/include/openvswitch/compiler.h b/include/openvswitch/compiler.h index 42c864f31..6e779f38f 100644 --- a/include/openvswitch/compiler.h +++ b/include/openvswitch/compiler.h @@ -183,18 +183,23 @@ #define OVS_PACKED(DECL) __pragma(pack(push, 1)) DECL __pragma(pack(pop)) #endif -/* For defining a structure whose instances should aligned on an N-byte - * boundary. - * - * e.g. The following: +/* OVS_ALIGNED_STRUCT may be used to define a structure whose instances should + * aligned on an N-byte boundary. This: * OVS_ALIGNED_STRUCT(64, mystruct) { ... }; * is equivalent to the following except that it specifies 64-byte alignment: * struct mystruct { ... }; + * + * OVS_ALIGNED_VAR defines a variable aligned on an N-byte boundary. For + * example, + * OVS_ALIGNED_VAR(64) int x; + * defines a "int" variable that is aligned on a 64-byte boundary. */ #ifndef _MSC_VER #define OVS_ALIGNED_STRUCT(N, TAG) struct __attribute__((aligned(N))) TAG +#define OVS_ALIGNED_VAR(N) __attribute__((aligned(N))) #else #define OVS_ALIGNED_STRUCT(N, TAG) __declspec(align(N)) struct TAG +#define OVS_ALIGNED_VAR(N) __declspec(align(N)) #endif /* Supplies code to be run at startup time before invoking main(). |