search for: rtm_newlink

...&change_info.info); > > > > This function no longer takes the dev parameter in the net-next kernel. > OK. Will get my patch updated with the latest net-next tree. > > > > > Did you consider calling netdev_state_change() although it does send a > > RTM_NEWLINK message too. May be just fixing the notifier call should be > > fine. > I did look at it and the extra RTM_NEWLINK message was indeed the reason I > got it rewritten. You see, how the way of initialization is inherited. > > Thanks, > -Siwei More messages just increase the cha...

...ge_info; > + > + change_info.flags_changed = 0; > + call_netdevice_notifiers_info(NETDEV_CHANGE, dev, > + &change_info.info); This function no longer takes the dev parameter in the net-next kernel. Did you consider calling netdev_state_change() although it does send a RTM_NEWLINK message too. May be just fixing the notifier call should be fine. > + } > + > ret = call_netdevice_notifiers(NETDEV_CHANGENAME, dev); > ret = notifier_to_errno(ret); > >

Changes since v9: * series re-ordering so make functionality more distinct. Basic vlan filtering is patches 1-4. Support for PVID/untagged vlans is patches 5 and 6. VLAN support for FDB/MDB is patches 7-11. Patch 12 is still additional egress policy. * Slight simplification to code that extracts the VID from skb. Since we now depend on the vlan module, at the time of input skb_tci is

This series of patches provides an ability to add VLANs to the bridge ports. This is similar to what can be found in most switches. The bridge port may have any number of VLANs added to it including vlan 0 priority tagged traffic. When vlans are added to the port, only traffic tagged with particular vlan will forwarded over this port. Additionally, vlan ids are added to FDB entries and become