On Sun, 2005-08-05 at 18:07 +1000, Herbert Xu wrote:
> On Sat, May 07, 2005 at 08:38:16AM -0400, jamal wrote:
> > Rewrite it Herbert ;-> I have no qualms as long as the feature is
> > available. I even promised not to harass you ;->
> Sorry, I can't think of any good ways to implement what you want.
There is really nothing in my (small) patch that you have pointed out
that is unresolvable;->
You just dont like the idea, period.
> > > The difference is that the uniqueness is easy when we (the kernel) are
> > > the only ones setting it. Once you let the user choose the value for
> > > index, that's where the horror starts.
> > But the uniqueness is still maintained. Nothing changes there.
> The difference is that we now have to guarantee the uniqueness of
> two unrelated fields during insertion: the index as well as the
> selector. This is where the complexity of your patch comes from.
Both the index and the selector MUST be unique, no question about that.
What i did is introduce setting of the index - and that makes the
checking do a little more. It would be worng not to do the checking.
> I'm afraid I don't buy this. The policies are not stored in a
> linear random-access data structure. So setting the index
> doesn't help performance one tiny bit.
> In future it'll probably become a hash table or a tree, in neither
> case will there be a linear index that could be used to determine
I am talking about user space apps - not the kernel.
Have you ever looked at IPSEC related MIBs and PIBs? or apps that
implement those sorts of entities? I suspect you have not otherwise we
would have closed this ages ago.
> Please elaborate by giving an example of how the index is actually
> used. Sorry, but as it is I'm too thick to see your point :)
I have given you enough info that i am concluding this is now becoming a
debate for the sake of one;->
Sorry, Herbert, I strongly disagree with your views on this topic. This
is one of those moments when it becomes obvious there can be no
compromise. So I am hoping that someone following this discussion or
writing management apps would speak up.
> > Having said the above, the SAD as well oughta have an index; infact one
> > exists (the reqid) but is quiet bizzare. I dont wanna touch the SAD,
> > yet ;-> not for the next few months until we talk at netconf probably.
> The reqid is definitely not an index. In fact it is not unique at all.
> It's a way of condensing all the fields in a SA template into one u32.
I dont wanna talk about this right now;