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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/27/2011 03:07 PM, Stefan Berger wrote:
This patch extends the NWFilter driver for Linux (ebiptables) to create
rules for each member of a previously introduced list. If for example
an attribute value (internally) looks like this:

IP = [10.0.0.1, 10.0.0.2, 10.0.0.3]

then 3 rules will be generated for a rule accessing the variable 'IP',
one for each member of the list. The effect of this is that this now
allows for filtering for multiple values in one field. This can then be
used to support for filtering/allowing of multiple IP addresses per
interface.

An interator is introduced that extracts each member of a list and

s/interator/iterator/

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?

+static int
+virNWFilterVarCombIterAddVariable(virNWFilterVarCombIterEntryPtr cie,
+                                  virNWFilterHashTablePtr hash,
+                                  const char *varName)
+{
+    virNWFilterVarValuePtr varValue;
+    unsigned int cardinality;
+
+    varValue = virHashLookup(hash->hashTable, varName);
+    if (varValue == NULL) {
+        virNWFilterReportError(VIR_ERR_INTERNAL_ERROR,
+                               _("Could not find value for variable '%s'"),
+                               varName);
+        return 1;
+    }

Again.

+
+    if (VIR_REALLOC_N(cie->varNames, cie->nVarNames + 1)<  0) {
+        virReportOOMError();
+        return 1;

Here too.

+    }
+
+    cie->varNames[cie->nVarNames] = varName;
+    cie->nVarNames++;
+
+    return 0;
+}
+
+/*
+ * 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/

+ * processed lists must be the same.
+ * The notation $ITEM1 and $ITEM2 (in one rule) therefore will always have to
+ * process the items in parallel. This could be an implicit notiation for

s/notiation/notation/

+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.

--
Eric Blake   eblake@xxxxxxxxxx    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]