Herbert,
Staring at the code, obversation:
-> PFKEY is going to be interesting to have it actually generate events
as a result of some app using netlink such as ip x - the reverse is
actually easier to deal with. This problem doesnt exist with current
approach i am taking.
The issue is that pfkey echoes back a few things from the original
message - important ones being version, pid, seq, and msgtype (as a
sample take a look at pfkey_add()). So these need to be remembered...
Brings back the original behavior i had netlink doing which was similar
(but innacurate now that i stare at this). At the time i carried the
nlmsg header around in the cb. So we would have to do the same for
netlink[1].
The good news is all these fields happen to exist on netlink (except for
the version - to which, for netlink created events, we could pass a
hardcoded matching PFKEY2).
In other words the structure i called km_cb will now have to have these
fields i mentioned above.
Thoughts before i start ?
cheers,
jamal
[1]I actually would have no problems using a pid/seq etc generated by
pfkey on a netlink header and viceversa. It shouldnt be an issue.
|