On Mon, 2005-09-05 at 07:40 +1000, Herbert Xu wrote:
> On Sun, May 08, 2005 at 09:56:33AM -0400, jamal wrote:
> > Why would someone need to deduce whether it has been deleted by index or
> > selector?
> It isn't just about deducing the message. It's about sending a delete
> message in the same format as we would receive them. As it is the
> delete message sent would be not be accepted if you sent it back to the
If you enumerate all netlink messages, you will see this is not always
the case. It is a nice but not a necessary condition; infact, not even
what you generate with that patch is _the same_ message that was sent
(you add new TLVs in the response that didnt exist in user->kernel).
What is necessary is that if i look at the event i know exactly what was
deleted. If i have such detail, i can build the message that was sent
from user->kernel to delete the object (because i know exactly what was
As an example:
I can derive the xfrm_usersa_id that was sent to the kernel if the event
sent me xfrm_usersa_info and therefore build the same a message that
will delete _exactly_ the same object.
It does get worse on occasion (I can point at tc filters) - where you
really cant derive the deleted object.
> > If yes, how do you distinguish the two cases when you are sending the
> > netlink event?
> Using the byid attribute that *you* introduced :)
Ok, theres no inconsistency then.
> > It doesnt seem to me what you provided in the patch produces exactly the
> > same thing that was sent by user space back in the event.
> That's not the point. The point is if you send exactly the same
> message to the kernel, even with the RTAs attached, the kernel
> would accept it and perform the deletion if there is a matching
So you are depending on the kernel not checking for the extra TLVs you
Refer to what i said above.
> > Heres what i will say so we can put this to rest:
> > The patch is unneeded (i hate to use strong words like bogus - but it is
> > getting close to that), but if you feel strongly about it just lets have
> > it well documented and provide the iproute2 patch as well.
> I'll leave the decision up to Dave.
Like i said: I think its extraneous stuff that is unneeded(what is in
there at the moment is sufficient detail) - but because theres no
inconsistency, i will not squirm in pain if it is included. I am
agreeing to disagree essentially ;->