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