[libvirt] [PATCH V1 0/6] Make part of inner workings of nwfilters more flexible

[Stefan Berger]

The following series of patches re-does some of the inner workings
of nwfilters with the goal to enable users to write filters that have other
than the system-known chains supported right now ('root','arp','rarp','ipv4'
and 'ipv6'). Ideally users should be able to provide a chain name in the
chains XML attribute and either be able to jump to it as an 'action' or 
have the chain created automatically as it is the case right now for those
chains enumerated before.

I am introducing internal priorities for the chains mentioned above so that
their creation can be made more flexible -- currently their creation and
the order in which they are accessed is hardcoded. This largely does away
with the hardcoded stuff.

Further, filters will be automatically accessed from the (ebtables) 
'root' chain using the prefix of the name of the chain. As an example, this
filter will be accessed from the root chain for 'arp' packets since its
name 'arpmac' has the prefix 'arp'.

<filter name='allow-arpmac' chain='arpmac'>
  <uuid>94abeecc-c956-0ac8-1f49-a06ee8995688</uuid>
  <rule action='accept' direction='out' priority='100'>
    <arp opcode='Request_Reverse' arpsrcmacaddr='$MAC' arpdstmacaddr='$MAC'
arpsrcipaddr='0.0.0.0' arpdstipaddr='0.0.0.0'/>
  </rule>
  <rule action='accept' direction='inout' priority='500'/>
</filter>

In the future the chains may have priorities supported in the XML in order to
control the order in which they are accessed.

<filter name='allow-arpmac' chain='arpmac' prirotiy='650'>
[...]

The series does not enable users yet to provide names of chains but instead
pushes the problem of their later enablement into the XML parser and
prepares the rest of the code to handle it (as far as this can be seen).

I did the testing with the test cases in libvirt-tck and did not see
regressions.

Regards,
    Stefan