* Herbert Xu <[EMAIL PROTECTED]> 2006-08-16 21:12 > On Wed, Aug 16, 2006 at 12:58:56PM +0200, Thomas Graf wrote: > > > > All route and tc notifications already use the pid so applications > > can decide whether the event was caused by them. A notification > > is a reply to a request so it doesn't even violate RFC 2367. > > Actually most IPv4 notifications *do* set the pid to zero which is > the right thing to do for kernel-generated messages. > > You're right though that the IPv6 notification modified by this patch > does set the pid to the netlink originator. Looking back in history > it seems that this behaviour was only introduced last year to a subset > of notifications.
It was added to help quagga identify which route modifications are self caused. It's not possible to use rtm_protocol for this purpose as other applications can delete routes added by quagga. > This inconsistency is very bad. IMHO this change (made last year) > should be reverted so that all kernel generated (broadcast) notifications > have the originator set to zero to match the source address of the > message. We can't just knowingly break quagga. I think it's a good thing to include the pid, it's additional information that is helpful to userspace. Userspace is already aware that the notifications are orignating from the kernel, we can't do userspace -> userspace communication anymore anyway. > Any notification that sets the netlink pid to current->pid is > *completely* bogus. Let me repeat this, the netlink pid is not > a process ID. Everyone is aware of that, actually these patches fix all occurences of current->pid by replacing them with a pid of 0. - 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
