Age | Commit message (Collapse) | Author |
|
With this implementation I get warnings with Clang on GNU/Linux when the
previous patch is not applied. This ought to make it easier to avoid
introducing new problems in the future even without building on FreeBSD.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jarno Rajahalme <jrajahalme@nicira.com>
|
|
I don't see any other way to make Clang realize that these are the real
mutex implementation functions.
I first noticed these warnings with Clang 1:3.4~svn188890-1~exp1.
I previously used version 1:3.4~svn187484-1~exp1.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
|
|
The Clang support for thread-safety annotations is much more effective
than "sparse" support. I found that I was unable to make the annotations
warning-free under sparse.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
|
|
An upcoming patch will add the first uses.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
This patch renames OVS_LOCKS_EXCLUDED to simply OVS_EXCLUDED so it's
more consistent with the other thread safety annotations. It also
adds it to the non-clang compilers.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
|
|
This commit adds annotations for thread safety check. And the
check can be conducted by using -Wthread-safety flag in clang.
Co-authored-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Alex Wang <alexw@nicira.com>
Signed-off-by: Ethan Jackson <ethan@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Signed-off-by: Linda Sun <lsun@vmware.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
The only tricky part here is that I'm throwing in annotations to allow
"sparse" to report unbalanced locking.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
|
|
An occasionally significant problem with the standard "assert" macro is
that it writes the failure message to stderr. In our daemons, stderr is
generally redirected to /dev/null. It's more useful to write the failure
message to the log, which is what the new ovs_assert macro introduced in
this patch does.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ethan Jackson <ethan@nicira.com>
|
|
OpenFlow actions have always been somewhat awkward to handle.
Moreover, over time we've started creating actions that require more
complicated parsing. When we maintain those actions internally in
their wire format, we end up parsing them multiple times, whenever
we have to look at the set of actions.
When we add support for OpenFlow 1.1 or later protocols, the situation
will get worse, because these newer protocols support many of the same
actions but with different representations. It becomes unrealistic to
handle each protocol in its wire format.
This commit adopts a new strategy, by converting OpenFlow actions into
an internal form from the wire format when they are read, and converting
them back to the wire format when flows are dumped. I believe that this
will be more maintainable over time.
Thanks to Simon Horman and Pravin Shelar for reviews.
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
Replaced all instances of Nicira Networks(, Inc) to Nicira, Inc.
Feature #10593
Signed-off-by: Raju Subramanian <rsubramanian@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
|
|
GCC allows __attribute__s to be included in function prototypes and
then omitted later on the function definition, but sparse complains about
this. Furthermore, sparse doesn't like the placement of the __attribute__s
that we tend to use in OVS.
I don't see any value in "fixing" these to suit sparse so it seems better
to just omit them.
|
|
|
|
__attribute__ is a GCC feature that we should not expose to other
compilers.
|
|
(The datapath uses these macros, but those come from Linux's kernel.h, not
from this file.)
|
|
There is no point in marking a well-aligned structure PACKED. It can only
cause trouble.
|
|
The main change here is the need to update all of the uses of UNUSED in
the next branch to OVS_UNUSED as it is now spelled on "master".
|
|
Requested by Jean Tourrilhes <jt@hpl.hp.com>.
|
|
|
|
|
|
|