<div> </div>-----Stefan Berger <a class="moz-txt-link-rfc2396E" href="mailto:stefanb@linux.vnet.ibm.com"><stefanb@linux.vnet.ibm.com></a> wrote: ----- > > The problem is that at the moment rules (in the 'root' table) can > have priorities [0, 1000]. So nothing prevents one to write a >rule > with priority 0. However, due to how nwfilters works right now >the > jumps into the protocol-specific tables will always be created > *before* those rules. I am trying to address this now with >assigning > negative numbers to the chains to achieve the same sorting and > maintain backwards compatibility. Priorities aren't directly line numbers, but I think extending negative numbers to be "from the end" as ebtables/iptables would be a useful thing (and less arcane due to the precedent already there). But since you are extending to allow more chains, couldn't you in fact just expose the root chain to XML and create a default that does the protocol switch that's generated in code now? Then, you could insert new chains before the standard ones, reorder, or do anything you want -- with "RETURN" as the policy or action for acceptable frames in the early chains so later chains are still run. If you didn't want to expose libvirt-{I,O}-vnetXX chains, couldn't you at least accomplish the same thing with new chains in the code-generated chains by adding a "pre-protocol" chain assuming "RETURN" is available. Then, a filter that adds to "pre-protocol" (or whatever you call it) would always happen before the standard chains. A similar chain hook could be done for post-protocol chains, if those were converted to do "RETURN" instead of ACCEPT/DROP too. > Using priorities in multiple places is very > like programming in basic > > and what both ebtables/iptables and nwfilters could use >better > I think would > > be the capability to label rules by name and reference the > label to identify the > > rule location. Then you might, e.g., add a rule at "myrules >+ > 5" and don't care > > what particular priority/line number "myrules" is. > > > > You have patches for that? Actually, you do. If the labels are new chains then the existing priority within that chain is essentially the same. But the existing priority mechanism doesn't have the full flexibility available in ebtables/iptables with "insert before", "append", "offset from beginning", "offset from end". Wouldn't you get that with the combination of user-defined chains, a user-modifiable root chain, and priorities interpretted like this: 0 - insert at beginning N - insert at N MAX - append at end (and this ought to be 2G-1, not 1000) -N - insert at END-N. ? +-DLS