[libvirt] [libvirt PATCHv3 07/10] support variable value changing
David Stevens
dlstevens at us.ibm.com
Mon Oct 17 17:43:40 UTC 2011
Stefan Berger <stefanb at linux.vnet.ibm.com> wrote on 10/17/2011 09:17:21
AM:
> > +int
> > +virNWFilterChangeVar(virConnectPtr conn,
....
> > + if (virNWFilterHashTablePut(vars, var, value, 1)) {
> > + virNWFilterReportError(VIR_ERR_INTERNAL_ERROR, _("Cound not
add "
> > + "variable \"%s\" to hashmap"), var);
> > + return 1;
> > + }
> > + rc = _virNWFilterInstantiateRec(conn,
> > + techdriver,
> > + nettype,
> > + filter,
> > + ifname,
> > + vars,
> > + NWFILTER_STD_VAR_IP, 0,
> > +&nEntries,&insts,
> > + INSTANTIATE_ALWAYS,&foundNewFilter,
> > + driver);
> Given the NWFILTER_STD_VAR_IP parameter, what does it give us at this
point?
I'm not sure I understand the question. NWFILTER_STD_VAR_IP (aka
"IP") is
the variable we want to match, so this will only affect rules that
reference "IP".
Rules that don't match are not included in the instantiation, and so are
unaffected.
> > + if (delete)
> > + rc = techdriver->removeRules(conn, ifname, nptrs, ptrs);
> > + else
> > + rc = techdriver->addRules(conn, ifname, nptrs, ptrs);
> I am wondering about this addRules() and whether the rules are being
> added to the end of a chain and thus the rules' assumed priority would
> have to be such that these rules can actually always be the last ones?
>
Where they are added depends on the original filter. If they have
a
priority associated with them, it'll use that. It's no different than the
original code's instantiation of rules referencing "IP" (other than that
this allows multiple occurrences). Without a priority, they appear at the
end of the chain.
+-DLS
More information about the libvir-list
mailing list