Now that the nwfilter driver keeps a list of bindings that it has
created, there is no need for the complex virt driver callbacks. It is
possible to simply iterate of the list of recorded filter bindings.

This means that rebuilding filters no longer has to acquire any locks on
the virDomainObj objects, as they're never touched.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Remove the unnecessary check as since commit id '46a811db' it is
not possible to add or alter a filter using the same name, but with
a different UUID.

NB: It's not required to provide a UUID for a filter by name, but
if one is provided, then it must match the existing. If not provided,
then one is generated during ParseXML processing.
Reviewed-by: NLaine Stump <laine@laine.org>
Reviewed-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rename the variable, recent review requested just use of @filter,
so be consistent throughout.

NB: Also change the virNWFilterPtr to be @nwfilter to not conflict
with the renamed variable.

This reverts commit b3e71a88.

As it turns out this ends up very badly as the @def could be Free'd
even though it's owned by @obj as a result of the AssignDef.

Create a common API to handle the instantiation path filter lookup.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Should compare < 0 to be correct.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

When adding a nwfilter onto the list in
virNWFilterObjListAssignDef() this array is re-allocated to match
demand for new size. However, it is never freed leading to a
leak:

==26535== 136 bytes in 1 blocks are definitely lost in loss record 1,079 of 1,250
==26535==    at 0x4C2E2BE: realloc (vg_replace_malloc.c:785)
==26535==    by 0x54BA28E: virReallocN (viralloc.c:245)
==26535==    by 0x54BA384: virExpandN (viralloc.c:294)
==26535==    by 0x54BA657: virInsertElementsN (viralloc.c:436)
==26535==    by 0x55DB011: virNWFilterObjListAssignDef (virnwfilterobj.c:362)
==26535==    by 0x55DB530: virNWFilterObjListLoadConfig (virnwfilterobj.c:503)
==26535==    by 0x55DB635: virNWFilterObjListLoadAllConfigs (virnwfilterobj.c:539)
==26535==    by 0x2AC5A28B: nwfilterStateInitialize (nwfilter_driver.c:250)
==26535==    by 0x5621C64: virStateInitialize (libvirt.c:770)
==26535==    by 0x124379: daemonRunStateInit (libvirtd.c:881)
==26535==    by 0x554AC78: virThreadHelper (virthread.c:206)
==26535==    by 0x8F5F493: start_thread (in /lib64/libpthread-2.23.so)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Only save the config when using a generated UUID if we were able to
create an object for the def. There could have been "other reasons"
for the assignment to fail, so saving the config could be incorrect.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move from virnwfilterobj.h to virnwfilterobj.c.

Create the virNWFilterObjListNew() API in order to allocate.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Prefix should have been virNWFilterObjList since the API is operating on
the list of filters.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Perform the object initialization in a helper rather than inline.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move the structure to virnwfilterobj.c and create necessary accessor API's
for the various fields.

Also make virNWFilterObjFree static since there's no external callers.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

It is what it is anyway, so let's describe it that way too.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

It was only ever set to false, which is ironically the default.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than dereferencing obj->def->XXX or nwfilters->objs[i]->X
create local virNWFilterObjPtr and virNWFilterDefPtr variables.

Future adjustments will be privatizing the object more, so this just
prepares the code for that reality.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

When processing a virNWFilterPtr use 'nwfilter' as a variable name.

When processing a virNWFilterObjPtr use 'obj' as a variable name.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Essentially code motion to move the ListExport function from nwfilter_driver
into virnwfilterobj
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Mostly code motion to move nwfilterConnectListNWFilters into nwfilterobj.c
and rename to virNWFilterObjGetNames.

Also includes a couple of variable name adjustments to keep code consistent
with other drivers.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Mostly code motion from nwfilter_driver to virnwfilterobj with one caveat
to add the virNWFilterObjListFilter typedef and pass it as an 'aclfilter'
argument to allow for future possible test driver adjustments to count
the number of filters (similar to how node device has done this).
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Use "virNWFilterObj" as a prefix for any external API in virnwfilterobj

Alter the format of the code to follow more recent style guidelines of
two empty lines between functions, function decls with "[static] type"
on one line followed by function name with arguments to functions each
on one line.

Move all the NWFilterObj API's into their own module virnwfilterobj
from the nwfilter_conf

Purely code motion at this point, plus adjustments to cleanly build.