> The documentation (design doc) quite clearly states how/why these > events are generated and all good programmers read documentation in > order to not be confused, right?
By that argument, we might as well name the constant NE_XYZZY. Obviously, the intent is also to describe the event. My view is that a good event description should include both the name of the object and the event occurring on it; thus NE_ADDRESS_CHANGE (or NE_ADDR_CHANGE) is good. > Adding/removing/changing an address is completely seperate > to the state of a network interface and nor should an address > change be mistaken for a logical interface being configured > up or even created. Presently, it stands to reason that you > could easily receive a NE_PLUMB followed by an NE_ADDRESS_CHANGE > followed by an NE_UP. Please don't spread the ifconfig lunacy of "plumbing" of logical interfaces; logical interfaces are added or removed, not plumbed. There is no kernel plumbing associated with them. > It could be said that this is a hole in the current design - > address change events can be delivered for logical intefaces > for which there is no other information received. But there > is currently no need for events that announce addition or > removal of logical interfaces. As Phil mentioned, having these makes the Clearview IP Observability code cleaner. > Lastly, if anyone has thoughts or ideas about expanding > (and/or changing) the set of events delivered (and/or the > information sent with them), I think it would be better > if this thread evolved (or a new one started) to discuss > how to do/design that, rather than continue to argue over > semantics/interpretations. I chimed in on this thread to correct the misunderstandings around the relationship between ipif_down() and ipif_down_tail(), and to encourage the team to generate the hooks in the same places where the routing socket messages are generated when reasonable. -- meem _______________________________________________ networking-discuss mailing list [email protected]
