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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list