[ovs-dev] [ext-244 3/4] Remove assumption that there are 64 or fewer fields.

[Jarno Rajahalme]

Sent from my iPhone

> On Jul 26, 2014, at 10:37 AM, Ben Pfaff <blp at nicira.com> 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?

  Jarno