if_link_state_change() patch for review
Sam Leffler
sam at errno.com
Wed Apr 20 14:27:13 PDT 2005
Gleb Smirnoff wrote:
> On Tue, Apr 19, 2005 at 08:27:19AM -0700, Sam Leffler wrote:
> S> >change message will report either all state changes or those where at
> S> >the time of reporting the state changed relative to the last report.
> S> >The same assumption is true for the OpenIGPd we are working on at the
> S> >moment.
> S>
> S> It is possible with the change to defer the messages to have multiple
> S> changes coalesced. If an app is written to assume it receives notice of
> S> every change and it uses this to track internal state then it can get
> S> confused. The issue was whether or not to communicate any coalescing to
> S> applications so they can recognize that it's happened. In lieu of doing
> S> that I asked for a console printf so we could see if it ever happened in
> S> practice.
>
> Yes, all the time we are speaking about a theoretical issue. Let's see
> whether it can happen or not. I decided to go ahead with this change.
>
> S> >From an (routing) application point of view only effective state changes
> S> >are interesting and only those should be provided.
> S> >
> S>
> S> If an inteface does down, moves network, then comes back up and you only
> S> get the up event then you will likely do the wrong thing unless you have
> S> some other way of identifying what happened. I'm not convinced (yet)
> S> this cannot happen so am being cautious.
>
> In this case you will receive additional messages, not only RTM_IFINFO.
> Move network will also generate RTM_NEWADDR and RTM_DELADDR
>
Only if someone sets the address which won't be true in the case I'm
thinking of: dhclient handling a wireless nic that re-associates with a
different ap. But since the dhclient I'm thinking of isn't in the tree
yet I'll look at the problem myself.
Sam
More information about the freebsd-net
mailing list