On 3/30/17 7:47 AM, Vlad Yasevich wrote: >>>>> But, NETDEV_PRECHANGEMTU will be a unnecessary notification to userspace >>>>> without >>>>> changes. There are already enough notifications generated for links (I >>>>> know you are not >>>>> suggesting adding it here) >>>> >>>> Actually, this one already triggers a link notification to userspace. It >>>> just has >>>> no event data in it to tell you that. :) >>> >>> Is it intentional or unintentional? perhaps rtnetlink_event should be a >>> whitelist -- events that userspace should be notified about. Seems like >>> NETDEV_ events have been added without rtnetlink_event getting updated. >> >> I think a 'whitelist' was attempted, but as you mentioned, it hasn't been >> updated... >> I'll defer the definitive answer to someone else. It seems Patrick added a >> comment >> in commit a2835763 to update the white list and it's been a few times. >> > > This is actually an interesting point. Looking at some commits that have > added > events to black list in rtnetlink-event, it might have been much easier to > debug > those issues if we had the 'event' encoding in the netlink message. > > I think it might be worthwhile to add all allowed event types to this new > encoding > so we can userspace can see just what's its getting. >
My point is that it is easy to add NETDEV events; takes extra effort to update rtnetlink_event to say "don't send a notification to userspace". A number of those events are for kernel processing, so why send anything to userspace? In that case a default of don't notify userspace and then having a list of events that should send the notification makes the intent explicit. Looking at git commit logs for NETDEV_PRECHANGEMTU, it seems that it was added for bonding and teaming to simplify kernel processing; userspace does not need to be notified so no intention there.
