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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
