Hi Jamal, first thanks for your long reply. I've moved the last part of your mail to the front to answer on it first. You've caught me, a lot of my networking experience involved cisco stuff ;-) Anyw
Hi Jamal, ok. Do all netdev people already know the patch or shall I repost it to this list? Is it possible to send (netlink) messages from a softirq? Anyway, in the tx/rx softirqs the check would be
Ok, I didnt know of this decision. In that case get rid of any calls directly modifying IFF_RUNNING in the drivers and have them make calls to netcarrier_*. LINK_STATE_NOCARRIER is also good enough
Two comments on this stuff: (A) I skimmed the 3.1.13 descriptions in RFC 2863. If RUNNING is to correspond to ifAdminStatus, and NO_CARRIER is inverted up/down ifOperStatus, this starts to make sense
Actually ifOperStatus == NO_CARRIER/IFF_RUNNING set NO_CARRIER is used to reflect IFF_RUNNING in serialized way. ifAdminStatus == IFF_UP Someone needs to enumarate a different truth table with IFF_UP
If i understand you correctly, this would still be something along the lines of dial on demand PPP. It stays "dormant" until it receives outgoing packet which initiates connection establishment acti
I meant this view from a "listener" perspective; example from an SNMP NMS perspective or even a dynamic route daemon, this is the only really interesting state transition. So IMO, it only makes sense
Author: Michael Richardson <mcr@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 07 Apr 2002 18:11:03 -0400
Are there docs on these interfaces somewhere? jamal> Good naming convention for the above two. jamal> Not clear on this one. PPP, for instance, does keepalives. An IPsec tunnel might also use such a
I guess this discussion will result in some documentation... Well, in that case the device is actually IFOP_UP. And the keepalives could be looked at as "carrier/link level diagnostics". Should the h
But ... how about "carrier on"? What else would be able to trigger software to bring the interface up (so it could be routed or bridged) if there were no notification for "carrier on"? Not expecting
Hi Jamal, they should. For a routing daemon it is interesting to be notified when interfaces becomes capable or incapable of handling packets, independant of the reason. As long as we abstract virtua
Well ... ok. Note, the user space program could maintain state and observe when all the interfaces are down to reach the same conclusion. Ok, Stefan, i think you should be ready to roll some code now
in the future can you please just post to netdev on networking related issues? I responded to lk, but feel free to remove it from the list. -I am not sure the idea of using a kernel thread is the be
For the uninitiated, here is where i saw it: http://marc.theaimsgroup.com/?l=linux-net&m=101751062827998&w=1 (sorry, i am not subscribed to lk) Why not? Moving it to softirq gives it more privilege;
Hi Jamal, first thanks for your long reply. I've moved the last part of your mail to the front to answer on it first. You've caught me, a lot of my networking experience involved cisco stuff ;-) Anyw
Hi Jamal, ok. Do all netdev people already know the patch or shall I repost it to this list? Is it possible to send (netlink) messages from a softirq? Anyway, in the tx/rx softirqs the check would be
Stefan, Ok, I didnt know of this decision. In that case get rid of any calls directly modifying IFF_RUNNING in the drivers and have them make calls to netcarrier_*. LINK_STATE_NOCARRIER is also good
Two comments on this stuff: (A) I skimmed the 3.1.13 descriptions in RFC 2863. If RUNNING is to correspond to ifAdminStatus, and NO_CARRIER is inverted up/down ifOperStatus, this starts to make sense
Actually ifOperStatus == NO_CARRIER/IFF_RUNNING set NO_CARRIER is used to reflect IFF_RUNNING in serialized way. ifAdminStatus == IFF_UP Someone needs to enumarate a different truth table with IFF_UP