On Jul 26, 2014, at 10:41 AM, Jarno Rajahalme <[email protected]> wrote:
> > > Sent from my iPhone > >> On Jul 26, 2014, at 10:37 AM, Ben Pfaff <[email protected]> wrote: >> >> On Sat, Jul 26, 2014 at 08:47:56AM -0700, Jarno Rajahalme wrote: >>>> +/* A set of mf_field_ids. */ >>>> +struct mf_bitmap { >>>> + unsigned long bm[BITMAP_N_LONGS(MFF_N_IDS)]; >>>> +}; >>>> +#define MF_BITMAP_INITIALIZER { { [0] = 0 } } >>> >>> Is this different from just { { 0 } } ? >> >> It has the same semantics, but it suppresses GCC warnings about >> only partially initializing an array. >> >>>> @@ -270,9 +276,9 @@ struct mf_field { >>>> * Also, some field types are tranparently mapped to each other via the >>>> * struct flow (like vlan and dscp/tos fields), so each variant supports >>>> * all protocols. */ >>>> - enum ofputil_protocol usable_protocols; /* If fully/cidr masked. */ >>>> + uint32_t usable_protocols; /* If fully/cidr masked. */ >>>> /* If partially/non-cidr masked. */ >>>> - enum ofputil_protocol usable_protocols_bitwise; >>>> + uint32_t usable_protocols_bitwise; >>> >>> These seem unrelated changes? >> >> This is actually a sticky point. Before this commit, meta-flow.h >> includes ofp-util.h, to get "enum ofputil_protocol" for these two >> members. After this commit, ofp-util.h includes meta-flow.h, to get >> struct mf_bitmap. The circular dependency causes a problem. The best >> solution I came up with was to change the "enum ofputil_protocol" >> members to uint32_t. It's not a great solution. Do you have a good >> idea? > > Can the enum be forward declared here instead? It seems C does not allow that, even if GCC does :-( Jarno _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
