All of lore.kernel.org
 help / color / mirror / Atom feed
From: jamal <hadi@cyberus.ca>
To: "Timo Teräs" <timo.teras@iki.fi>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	netdev@vger.kernel.org, David Miller <davem@davemloft.net>
Subject: Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
Date: Thu, 17 Jan 2008 07:42:30 -0500	[thread overview]
Message-ID: <1200573750.4508.29.camel@localhost> (raw)
In-Reply-To: <478EED98.6080603@iki.fi>

On Thu, 2008-17-01 at 07:54 +0200, Timo Teräs wrote:

> You listen for the events. It is guaranteed that if the dumping code
> does return the entry to be deleted, the deletion notification will
> occur after that dump entry.

Ok, sounds reasonable - as long as there is a known order for
occurances, then there will be no ambiguity.
I am assuming that the same ordering will happen with
updates/modifications?
To go back to what i suggested earlier - is it possible to have this in
two stages? First pfkey with expected behavior being the same as current
netlink; then later the optimizations you are talking about.

Looking at the pfkey RFC one more time, heres a funny quote:
"
The dump message is used for debugging
purposes only and is not intended for production use.
"

One thing Dave mentioned thats extremely important is to ensure no ABI breakage. 
Think of racoon 0.6 which knows nothing of this; it should continue to work.

Dave: One reason i paid attention to this is because it was on your TODO
list from netconf 2005 ;-> It has just been sitting in the background
memory cells since.

cheers,
jamal


  parent reply	other threads:[~2008-01-17 12:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-13 12:26 [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key Timo Teräs
2008-01-16 13:52 ` jamal
2008-01-16 14:28   ` Timo Teräs
2008-01-17  1:25     ` jamal
2008-01-16 22:58   ` Herbert Xu
2008-01-17  1:39     ` jamal
2008-01-17  2:17       ` Herbert Xu
2008-01-17  5:54         ` Timo Teräs
2008-01-17 11:11           ` Herbert Xu
2008-01-17 12:21             ` Timo Teräs
2008-01-17 12:26             ` jamal
2008-01-17 12:42           ` jamal [this message]
2008-01-17 12:50             ` Herbert Xu
2008-01-17 13:18               ` jamal
2008-01-17 13:31               ` Timo Teräs
2008-01-17 21:34                 ` Herbert Xu
2008-01-18  6:45                   ` Timo Teräs
2008-01-18 14:08                     ` jamal
2008-01-17  6:27     ` Timo Teräs
2008-01-17  7:16       ` David Miller
2008-01-17  7:38         ` Timo Teräs
2008-01-17  7:59           ` David Miller
2008-01-17  8:11             ` Timo Teräs
2008-01-17  8:49               ` David Miller
2008-01-17  9:20                 ` Timo Teräs
2008-01-17  9:31                   ` David Miller
2008-01-17  9:38                     ` Timo Teräs
2008-01-17  9:44                       ` David Miller
2008-01-17 10:01                         ` Timo Teräs
2008-01-17 10:06                           ` David Miller
2008-01-17 11:00                             ` Timo Teräs
2008-01-17 11:08                               ` David Miller
2008-01-17 12:37                                 ` Timo Teräs

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=1200573750.4508.29.camel@localhost \
    --to=hadi@cyberus.ca \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=timo.teras@iki.fi \
    /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.