From: jamal <hadi@cyberus.ca>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>,
Masahide NAKAMURA <nakam@linux-ipv6.org>,
Patrick McHardy <kaber@trash.net>, netdev <netdev@oss.sgi.com>
Subject: Re: [7/7] [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification
Date: Sat, 07 May 2005 08:46:44 -0400 [thread overview]
Message-ID: <1115470004.19561.49.camel@localhost.localdomain> (raw)
In-Reply-To: <20050507122504.GA21693@gondor.apana.org.au>
On Sat, 2005-07-05 at 22:25 +1000, Herbert Xu wrote:
> On Sat, May 07, 2005 at 08:04:16AM -0400, jamal wrote:
> >
> > This is incosistent in two ways:
> > 1) Typical netlink behavior is to return the object being deleted.
> > Every other netlink user behaves that way - the only exception is sone
> > filters in tc and this is because they cant retrieve that detail
> > (something that needs resolution at some point). There is nothing that
> > xfrm_usersa_id provides that can be found in xfrm_usersa_info.
> > Same for the policy.
>
> This analogy is flawed since unlike other rtnetlink delete operations
> the xfrm delete operations do not carry the same payload type as their
> add/update cousins.
>
No, this is not true. Study the tc code.
It is nice to be able to return exactly the same detail - user space can
then infer what exactly happened. It is nicer to be able to return more
detail because user space doesnt have to infer anything.
> > 2) You cant have one behavior when something is deleted by pfkey and a
> > different one when it is deleted by netlink.
>
> As far as I can see the behaviour is identical.
>
If this is true, then #1 is forgivable. This was my main concern.
You describe the patch this way
---
This patch changes the format of the XFRM_MSG_DELSA and
XFRM_MSG_DELPOLICY notification so that the main message
sent is of the same format as that received by the kernel
if the original message was via netlink.
----
That it only happens when you delete via netlink. Is this not so?
cheers,
jamal
next prev parent reply other threads:[~2005-05-07 12:46 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-05 12:03 PATCH: IPSEC xfrm events jamal
2005-04-05 12:07 ` Herbert Xu
2005-04-05 12:19 ` jamal
2005-04-05 12:24 ` Arnaldo Carvalho de Melo
2005-04-09 10:54 ` [1/4] [IPSEC] Improve xfrm to pfkey SA state conversion Herbert Xu
2005-04-09 11:12 ` [2/4] [IPSEC] Kill spurious hard expire messages Herbert Xu
2005-04-09 11:15 ` [3/4] [IPSEC] Turn km_event.data into a union Herbert Xu
2005-04-10 7:48 ` [4/4] [IPSEC] Set byid for km_event in xfrm_get_policy Herbert Xu
2005-04-10 9:02 ` [5/*] [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_* Herbert Xu
2005-04-10 9:38 ` [6/*] [IPSEC] Add xfrm_userpolicy_delete for xfrm_user notification Herbert Xu
2005-04-10 14:15 ` [5/*] [IPSEC] Use XFRM_MSG_* instead of XFRM_SAP_* jamal
2005-04-10 21:28 ` Herbert Xu
2005-04-11 5:45 ` Masahide NAKAMURA
2005-04-11 11:26 ` jamal
2005-04-12 8:17 ` Masahide NAKAMURA
2005-04-12 13:37 ` jamal
2005-04-13 5:07 ` Masahide NAKAMURA
2005-04-09 12:30 ` [2/4] [IPSEC] Kill spurious hard expire messages jamal
2005-04-09 19:29 ` Herbert Xu
2005-04-09 20:03 ` Herbert Xu
2005-04-10 14:10 ` jamal
2005-04-10 21:27 ` Herbert Xu
2005-04-11 11:20 ` jamal
2005-04-11 11:30 ` Herbert Xu
2005-04-11 11:57 ` jamal
2005-04-11 12:08 ` Herbert Xu
2005-05-07 7:14 ` [0/7] [IPSEC] IPsec event notification Herbert Xu
2005-05-07 7:18 ` [1/7] [IPSEC] Add complete xfrm " Herbert Xu
2005-05-07 7:18 ` Herbert Xu
2005-05-07 7:19 ` [2/7] [IPSEC] Fix xfrm to pfkey SA state conversion Herbert Xu
2005-05-07 7:20 ` [3/7] [IPSEC] Kill spurious hard expire messages Herbert Xu
2005-05-07 7:21 ` [4/7] [IPSEC] Turn km_event.data into a union Herbert Xu
[not found] ` <20050507072216.GF5753@gondor.apana.org.au>
[not found] ` <20050507072251.GG5753@gondor.apana.org.au>
[not found] ` <20050507072349.GH5753@gondor.apana.org.au>
2005-05-07 12:04 ` [7/7] [IPSEC] Add XFRMA_SA/XFRMA_POLICY for delete notification jamal
2005-05-07 12:25 ` Herbert Xu
2005-05-07 12:46 ` jamal [this message]
2005-05-07 19:35 ` Herbert Xu
2005-05-08 13:56 ` jamal
2005-05-08 21:40 ` Herbert Xu
2005-05-09 0:06 ` jamal
2005-05-07 14:51 ` [1/7] [IPSEC] Add complete xfrm event notification Patrick McHardy
2005-05-07 19:42 ` Herbert Xu
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=1115470004.19561.49.camel@localhost.localdomain \
--to=hadi@cyberus.ca \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=kaber@trash.net \
--cc=nakam@linux-ipv6.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.