jamal wrote: > On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote: >> > No. I'm not creating second copies of the SADB/SPD entries. The entries >> > are just added to one more list. > > Ah, sorry - yes, that sounds reasonable. > So what happens if i delete an entry; does it get removed from the list? > Also what happens on modification?
If the entry is removed befored it is dumped, it wont be dumped at all. The state during dump code execution is returned. Depending when the modification occurs it might or might not be reflected in the dumped entry. >> > If more entries are added, you can get notifications of them. > > how would a user app (example racoon) appropriately deal with it? > Example an entry sits in the dump-list, it gets deleted - an event gets > generated user-space and later that entry shows up in user space dump. 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. Herbert Xu wrote: > On Wed, Jan 16, 2008 at 08:39:40PM -0500, jamal wrote: >> I wouldnt disagree except some apps like racoon which depend on pfkey >> are unfortunately beyond repair. Timo has a pretty good handle on the > > Racoon doesn't use pfkey dumping as far as I know. ipsec-tools racoon uses pfkey and only pfkey. And it's non trivial to make it use netlink; it relies heavily all around the code to pfkey structs. It also runs on BSD so we cannot rip pfkey away; adding a layer to work with both pfkey and netlink would be doable, but just a lot of work. Also ipsec-tools racoon seems to be the default IKE daemon in some popular distros. So for the time being I think pfkey is an evil we have to live with. Cheers, Timo -- 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
