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 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).