From: jamal <hadi@cyberus.ca>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>, netdev <netdev@oss.sgi.com>
Subject: Re: resend patch: xfrm policybyid
Date: Thu, 05 May 2005 22:10:03 -0400 [thread overview]
Message-ID: <1115345403.7660.49.camel@localhost.localdomain> (raw)
In-Reply-To: <20050506013125.GA31780@gondor.apana.org.au>
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
next prev parent reply other threads:[~2005-05-06 2:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-05 13:14 resend patch: xfrm policybyid jamal
2005-05-05 21:32 ` Herbert Xu
2005-05-05 22:17 ` jamal
2005-05-05 22:18 ` David S. Miller
2005-05-06 13:28 ` Herbert Xu
2005-05-06 18:20 ` David S. Miller
2005-05-05 23:12 ` Herbert Xu
2005-05-06 1:15 ` jamal
2005-05-06 1:31 ` Herbert Xu
2005-05-06 2:10 ` jamal [this message]
2005-05-06 2:20 ` jamal
2005-05-06 8:54 ` Herbert Xu
2005-05-06 11:53 ` jamal
2005-05-07 10:55 ` Herbert Xu
2005-05-07 12:38 ` jamal
2005-05-08 8:07 ` Herbert Xu
2005-05-08 14:30 ` jamal
2005-05-08 15:23 ` Patrick McHardy
2005-05-08 17:23 ` jamal
2005-05-09 11:45 ` Patrick McHardy
2005-05-09 13:10 ` jamal
2005-05-06 11:04 ` Herbert Xu
2005-05-06 11:56 ` jamal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1115345403.7660.49.camel@localhost.localdomain \
--to=hadi@cyberus.ca \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).