From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Tue, 19 Sep 2006 00:08:00 +0900 (JST)
> [XFRM]: Do not add a state whose SPI is zero to the SPI hash. > > SPI=0 is used for acquired IPsec SA and MIPv6 RO state. > Such state should not be added to the SPI hash > because we do not care about it on deleting path. > > Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]> > Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Patch applied, thank you. But the rest of these patches need more thought about these header file issues. > [NET]: Move netlink interface bits to linux/if_link.h. > > Moving netlink interface bits to linux/if.h is rather troublesome for > applications including both linux/if.h (which was changed to be included > from linux/rtnetlink.h automatically) and net/if.h. > > Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> If it is illegal for user to include kernel's linux/if.h (by any means) if he uses net/if.h from userland headers, then he should also avoid including the kernel's rtnetlink.h header too. I understand the issue, in that net/if.h defines macros that linux/if.h defines as well so there are conflicts (even though in the end the same exact values are used). What I see happening is that the troublesome interfaces move from linux/if.h to a new file named linux/if_addr.h, then this gets included again to linux/rtnetlink.h but only for userspace with some messy ifdefs. These kinds of things don't go away, they stay around forever once you decide to support them. Actually, what I'm going to do is apply: [NET]: Move netlink interface bits to linux/if_link.h. [NET] KBUILD: Add missing entries for new net headers. And leave the rest for now. Thank you. - 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
