Herbert, I think this is a reasonable thing to have. I should be able to update (just like delete or get) a policy by id. And that it trumps a selector when both are specified.. I am assuming ids are
Sorry, cant test, have to rush to work - and it looks like the priorities may interfere. I will test when i get back home. It also appears there may be a bug in ip x. cheers, jamal
I have no problems with the idea itself. However, I have a couple of minor issues with this patch :) First of all please align the continued lines to the if expression, e.g., if (!delpol && (policy->
np. sorry, i was rushing out - testing as we speak. the policy->index is only relevant for the update not the add; the update could also be done by selector. So i didnt follow. cheers, jamal
I see. In that case you want to change your expression above so that the memcmp is never done if excl is off and the index is non-zero. Otherwise this will result in non-deterministic behaviour as th
Sorry, the index match needs more work. We need to maintain these invariants: 1) There is only one policy with a given selector. 2) There is only one policy with a given index. So to allow matching b
I found a bug in the kernel that i initially thought was in "ip x p". If you specify an index when creating a new rule, the kernel overrides it regardless. So i can now update by index with attached
Please see my last email. To do index updates correctly we'll need to modify the current code so that it is able to delete two existing policies. We may have two existing policies if one matches the
Well, while snooping i was bothered as well. I am not sure i agree with your #1 above ;-> 1) It would seem to me that the priority field is to be used as a ambiguity resolver (thats what a gazillion
And you my other email ;-> i think if we say index is unique per direction then lets settle in rejecting adds which try to reinsert the same index. So theres no ambiguity in deleting by index. Not sp