netdev
[Top] [All Lists]

Re: patch: policy update by id

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: patch: policy update by id
From: jamal <hadi@xxxxxxxxxx>
Date: Wed, 27 Apr 2005 21:59:54 -0400
Cc: netdev@xxxxxxxxxxx
In-reply-to: <20050428014818.GA23148@xxxxxxxxxxxxxxxxxxx>
Organization: unknown
References: <1114602874.7670.4.camel@xxxxxxxxxxxxxxxxxxxxx> <1114604657.7670.22.camel@xxxxxxxxxxxxxxxxxxxxx> <1114604826.7670.24.camel@xxxxxxxxxxxxxxxxxxxxx> <20050427233924.GA22238@xxxxxxxxxxxxxxxxxxx> <1114650816.7663.13.camel@xxxxxxxxxxxxxxxxxxxxx> <20050428012135.GA22950@xxxxxxxxxxxxxxxxxxx> <1114652680.7663.31.camel@xxxxxxxxxxxxxxxxxxxxx> <20050428014818.GA23148@xxxxxxxxxxxxxxxxxxx>
Reply-to: hadi@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
On Thu, 2005-28-04 at 11:48 +1000, Herbert Xu wrote:
> On Wed, Apr 27, 2005 at 09:44:40PM -0400, jamal wrote:
> > 
> > > 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.
> > 
> > Hrm. Thinking... So you want to exclude the selector check if someone
> > updating ever specified the index? That may change things a little, no?
> > Give me a clever expression.
> 
> Please see my last email.

And you my other 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 index
> while the other matches the selector.
> 

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 specifying the index means one which is unique is generated by the
kernel.
Specifying x rules with exact same selector in absence of a index i
believe should be allowed. There the disambiguation in add is via the
priority. Deleting of such entries should be per first seen i.e highest
priority.  
Thoughts?

cheers,
jamal


<Prev in Thread] Current Thread [Next in Thread>