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

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