[libvirt] [PATCH V4 2/4] Create rules for each member of a list

[Stefan Berger]

On 10/28/2011 05:26 PM, Eric Blake wrote:
> On 10/27/2011 03:07 PM, Stefan Berger wrote:
>
>
>> puts it into a hash table which then is passed to the function creating
>> a rule. For the above example the iterator would cause 3 loops.
>>
>> +ebiptablesCreateRuleInstanceIterate(
>> +                             virConnectPtr conn ATTRIBUTE_UNUSED,
>> +                             enum virDomainNetType nettype 
>> ATTRIBUTE_UNUSED,
>> +                             virNWFilterDefPtr nwfilter,
>> +                             virNWFilterRuleDefPtr rule,
>> +                             const char *ifname,
>> +                             virNWFilterHashTablePtr vars,
>> +                             virNWFilterRuleInstPtr res)
>> +{
>> +    int rc = 0;
>> +    virNWFilterVarCombIterPtr vciter;
>> +
>> +    /* rule->vars holds all the variables names that this rule will 
>> access.
>> +     * iterate over all combinations of the variables' values and 
>> instantiate
>> +     * the filtering rule with each combination.
>> +     */
>> +    vciter = virNWFilterVarCombIterCreate(vars, rule->vars, 
>> rule->nvars);
>> +    if (!vciter)
>> +        return 1;
>
> Shouldn't we go with the more typical convention of -1 on error?
Fixed in this file now.
>> +/*
>> + * Create an iterator over the contents of the given variables. All 
>> variables
>> + * must have entries in the hash table.
>> + * The iterator that is created processes all given variables in 
>> parallel,
>> + * meaning it will access $ITEM1[0] and $ITEM2[0] then $ITEM1[1] and 
>> $ITEM2[1]
>> + * upto $ITEM1[n] and $ITEM2[n]. For this to work, the cardinality 
>> of all
>
> s/upto/up to/
fixed all spelling mistakes

>> +typedef struct _virNWFilterVarCombIter virNWFilterVarCombIter;
>> +typedef virNWFilterVarCombIter *virNWFilterVarCombIterPtr;
>> +struct _virNWFilterVarCombIter {
>> +    virNWFilterHashTablePtr hashTable;
>> +    virNWFilterVarCombIterEntry iter[1];
>
> 1-element arrays look odd,
>
>> +    unsigned int nIter;
>> +};
>
> especially when they aren't the last element of a struct.
>
Yes, that was a misordering. Now it's also [0].

    Stefan