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