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

Eric Blake eblake at redhat.com
Fri Oct 28 21:26:37 UTC 2011


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 at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org




More information about the libvir-list mailing list