> On Thu, 8 Sep 2016 11:30:08 -0700 > Florian Fainelli <f.faine...@gmail.com> wrote: > >> On 09/08/2016 10:19 AM, D. Herrendoerfer wrote: >>> >>> On 08 Sep 2016, at 17:39, Stephen Hemminger <step...@networkplumber.org> >>> wrote: >>> >>>> On Thu, 8 Sep 2016 15:06:16 +0200 >>>> "D. Herrendoerfer" <d.herrendoer...@herrendoerfer.name> wrote: >>>> >>>>> Hello, >>>>> >>>>> I'd like to start a discussion if it makes sense to add an optional >>>>> feature >>>>> >>>>> to the bridge MAC address learning code to generate kernel uevents for >>> >>> [SNIP] >>> >>>>> >>>>> I'm porting my patch (for 3.10.0) to head, and will make it available, I >>>>> just want some >>>>> >>>>> valuable feedback as early as possible. >>>>> >>>>> >>>>> Thanks, D.Herrendoerfer >>>> >>>> This should be possible by listening for netlink events. >>>> No need for udev interaction. >>> >>> No, there are none, not for changes to the bridge forwarding table, also >>> this would >>> require a tool to continuously listen for changes. >> >> Wat do you expect uevent to solve here that netlink + a monitoring >> program can't? >> >> There is quite a bit of code in net/bridge/br_fdb.c just to deal with >> notifying learned/added MAC addresses, is not that where you should >> start adding what you are after (if that is not supported as of latest >> mainline)? > > just like neighbor table modifications, it should be possible to listen for > events with netlink. Doing it through uevent is the wrong model.
I agree partially - but consider: we plug hardware - we get an event we remove hardware - we get an event we add a virtual interface - we get an event we add a bridge - event we add an interface to that bridge - event a kvm guest starts using the interface on that bridge - we need to monitor netlink, poll brforward, capture traffic It seems inconsistent, bridge is already emitting events.
