Folks, I just scanned really quickly so maybe missing things ..
I will try and list the contended issues and my comments below. Again, I may have missed something since it was a quick scan. 1) In regards to the connected routes: - I would agree that there is need to do something about them - but i dont think those extra L3* states are the answer. So Stefan, we need to kill the L3* thingy IMO. >From an adjacency perspective this is no different than the kernel resolving arp request and then obsoleting it when the neighbor fails to respond. If arp is run in user space however, it will be upto user space to take care of this. The link change notification should be handled by the fib code as if it was an admin notification. 2) on admin and operational status relationships: I dont think we need to explicitly set the operational states on admin state transitions. The logic should be sufficient to be of the form: if admin up && oper status up then bleh.. in other words short circuit if the first condition fails. And i think this is what the code does already. Setting links to operational down/up based on admin status would result in each of those transitions now checking for operational status. Summary: lets not set any oper status on admin changes. 3) On case of _who_ sets the link oper transitioning. I think i didnt follow this well in the quick scan. At the moment if this is done via the driver, the are no known issues in atomicity. In the case of protocol based link administration such as the case referred to for 802.1x, i am not sure i see the issue. Can someone please explain it? anything from user space wont reenter the kernel as long as we have the rtnl semaphore (which we do); and if the flags are being protected by the dev base lock, where is the problem? 4) it would probably be a good idea to use a u8 instead of uchar for the oper flags cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
