netdev
[Top] [All Lists]

Re: resend patch: xfrm policybyid

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: resend patch: xfrm policybyid
From: jamal <hadi@xxxxxxxxxx>
Date: Thu, 05 May 2005 22:10:03 -0400
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev <netdev@xxxxxxxxxxx>
In-reply-to: <20050506013125.GA31780@gondor.apana.org.au>
Organization: unknown
References: <1115298877.7680.75.camel@localhost.localdomain> <20050505213239.GA29526@gondor.apana.org.au> <1115331436.8006.112.camel@localhost.localdomain> <20050505231210.GA30574@gondor.apana.org.au> <1115342122.7660.25.camel@localhost.localdomain> <20050506013125.GA31780@gondor.apana.org.au>
Reply-to: hadi@xxxxxxxxxx
Sender: netdev-bounce@xxxxxxxxxxx
On Fri, 2005-06-05 at 11:31 +1000, Herbert Xu wrote:
> On Thu, May 05, 2005 at 09:15:22PM -0400, jamal wrote:
> > 
> > Thats a moot point really Herbert. I can think of a few apps that can
> > use this, but it shouldnt matter: The main point is correctness.
> 
> Ah, that's why we're talking past each other :) You're looking at
> it as a bug where we aren't setting the index when it is provided
> by the user.

It is a bug based on what common usage of what indices are used for in
tables. They are search keys.

> The way I'm seeing it is that the index is simply a read-only value
> that's only provided by the kernel to the user as an aid in locating
> policies.
> 

IOW, they are search keys. 
Search keys are unique and read-write. You cant just invent you rules
Herbert ;->
The typical rules are simple for indices:
a) you specify the index - if it doesnt conflict, it is accepted. You
can then use that key to search in the future
b) you dont specifiy the index, the kernel specifies one for you which
doesnt conflict.

We do b) only and override a). 

Look at these as array subscripts if you want an analogy. You can
reference an empty array slot but not one thats being used. If you dont
specify the array index then the kernel will provide one for you.

> In this respect it's just like xfrm_policy->curlft, it can be read
> by the user by it's only ever written by the kernel.  So whatever
> value the user provides us when adding/updating a policy is simply
> ignored.
> 

Theres a difference;-> you cant search by curlft i.e its not a key.

> Another way to look at it is that it's a handle that we're returning
> to the user so that they can talk about policies in an unambiguous way.
> 
> Does this make sense?
> 

You are emphasizing the uniqueuness feature of a search key ;->

> > You know what else you can do is get rid of the index totaly - that
> > would be fine with me. What do you say to that?
> 
> That would break user API/ABI so no :)

Understood.
There are a lot of things i think need fixing in both the SPD and SAD
that i am not touching - this is certainly one that i dont want to leave
alone. 

The other issues i will leave to another discussion  without distracting
this one;->

cheers,
jamal


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