I saw following error while testing this series.
---8<---
In file included from lib/smap.c:16:
./lib/smap.h:75:56: warning: declaration of 'struct in6_addr' will not be visible outside of this function [-Wvisibility]
void smap_add_ipv6(struct smap *, const char *, struct in6_addr *);
^
lib/smap.c:102:1: error: conflicting types for 'smap_add_ipv6'
smap_add_ipv6(struct smap *smap, const char *key, struct in6_addr *addr)
^
./lib/smap.h:75:6: note: previous declaration is here
void smap_add_ipv6(struct smap *, const char *, struct in6_addr *);
Signed-off-by: Pravin B Shelar <pshelar@ovn.org>
Acked-by: Ben Pfaff <blp@ovn.org>
Some of our data structures derived from hmap use the same member names.
This means it's possible to confuse them in iteration, e.g. to iterate a
shash with SIMAP_FOR_EACH. Of course this will crash at runtime, but it
seems even better to catch it at compile time.
An alternative would be to use unique member names, e.g. shash_map and
simap_map instead of just map. I like short names, though.
It's kind of nasty that we need support from the hmap code to do this.
An alternative would be to insert the build assertions as statements before
the for loop. But that would cause nasty surprises if someone forgets the
{} around a block of statements; even though the OVS coding style requires
them in all cases, I suspect that programmers doing debugging, etc. tend
to omit them sometimes.
It's not actually necessary to have multiple variants of these macros,
e.g. one can write a C99-compliant HMAP_FOR_EACH that accepts 3 or 4 or
more arguments. But such a macro is harder to read, so I don't know
whether this is a good tradeoff.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Andy Zhou <azhou@ovn.org>
These functions will be used by the next patches.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
Reviewing the ovn-controller code I started to notice a common pattern:
struct smap ext_ids = SMAP_INITIALIZER(&ext_ids);
smap_add(&ext_ids, "ovn-patch-port", network);
ovsrec_port_set_external_ids(port, &ext_ids);
smap_destroy(&ext_ids);
This seemed like a bit too much code for something as simple as
initializing an smap with a single key-value pair. This commit allows the
code to be reduced to just:
const struct smap ids = SMAP_CONST1(&ids, "ovn-patch-port", network);
ovsrec_port_set_external_ids(port, &ids);
This new form also eliminates multiple memory allocation and free
operations, but I doubt that has any real effect on performance;
the primary goal here is code readability.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Russell Bryant <rbryant@redhat.com>
Add a method to determine of two smaps are equal (have the exact same
set of key-value pairs).
Suggested-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Russell Bryant <rbryant@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
The following macros are renamed to avoid conflicts with other headers:
* WARN_UNUSED_RESULT to OVS_WARN_UNUSED_RESULT
* PRINTF_FORMAT to OVS_PRINTF_FORMAT
* NO_RETURN to OVS_NO_RETURN
Signed-off-by: Thomas Graf <tgraf@noironetworks.com>
Acked-by: Ben Pfaff <blp@nicira.com>
An upcoming commit will add a caller that needs to format both the key and
the value. That isn't cleanly possible with the current interface.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Gurucharan Shetty <gshetty@nicira.com>
"smap" is now the appropriate data structure for a string-to-string map.
Also changes ovsdb_datum_from_shash() into ovsdb_datum_from_smap() since
system-stats related code was the only client.
Signed-off-by: Ben Pfaff <blp@nicira.com>
A smap is a string to string hash map. It has a cleaner interface
than shash's which were traditionally used for the same purpose.
This patch implements the data structure, and changes netdev and
its providers to use it.
Signed-off-by: Ethan Jackson <ethan@nicira.com>
