Does anyone have an opinion or insight on this? Janice __________________________________________________________________ Janice Girouard girouard@xxxxxxxxxx 512-838-7981 -- Forwarded by Janice Girou
It is not a physical state change. This state bit is meant only as a hack for the isdn layers dial on demand like functionality. This is not the kind of state change the notifier chain listeners are
<snip> (presuming first that these events can be propagated up to user space through some kind of listen on a socket style API, something that I don't think is possible _yet_) I beg to differ a littl
When I look at the timer.c code in the tulip directory, I can see that ethernet drivers are already using this flag to show the health of the card. I also see * xircom_cb.c set's this flag to show a
Consider these states, which most network drivers go through in about this order (if they distinguish them): (a) network interface (hardware) is present (b) interface is registered (c) hardware is co
Not the current ones. It would be useful in some cases to trigger a TCP retransmit though. This is needed for good behaviour on dynamic IP addresses with the ip_dynaddr hack. ip_dynaddr can only rewr
I either implemented these or suggested implementation to the driver authors... Alexey implemented netif_carrier_foo for tulip. I didn't put it into other drivers when someone (at the Summit?) pointe
I'm not sure I understand your comment. When you say "But it does seem to me that transitions to state (c) above are problematic just now." are you saying you don't think that we are currently able t
It's only a local marking. If Andi implements a mechanism and first client for it, then that'll fix this issue. I want to know exactly what that transition means, too. Notice that I was putting this
As well as SCTP could use this for failover. If i am not mistaken it was Alexey that removed this from the netlink interface sometime around 2.3. The problem was that link notification was done at in
I believe these events get sent to the cardmgr daemon and it does all the ifconf magic to change the device state. Later, David S. Miller davem@xxxxxxxxxx
schedule_task(). The now-standard way of punting asynchronous events up into process context. Yeah, we need to sort out the netif_carrier stuff. Some userspace apps want async notifications when the
Does anyone have an opinion or insight on this? Janice __________________________________________________________________ Janice Girouard girouard@xxxxxxxxxx 512-838-7981 -- Forwarded by Janice Girou
It is not a physical state change. This state bit is meant only as a hack for the isdn layers dial on demand like functionality. This is not the kind of state change the notifier chain listeners are
Author: Roger Venning <c729953@xxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 4 May 2001 16:07:24 +1000 (EST)
<snip> (presuming first that these events can be propagated up to user space through some kind of listen on a socket style API, something that I don't think is possible _yet_) I beg to differ a littl
When I look at the timer.c code in the tulip directory, I can see that ethernet drivers are already using this flag to show the health of the card. I also see * xircom_cb.c set's this flag to show a
Consider these states, which most network drivers go through in about this order (if they distinguish them): (a) network interface (hardware) is present (b) interface is registered (c) hardware is co
Not the current ones. It would be useful in some cases to trigger a TCP retransmit though. This is needed for good behaviour on dynamic IP addresses with the ip_dynaddr hack. ip_dynaddr can only rewr
I either implemented these or suggested implementation to the driver authors... Alexey implemented netif_carrier_foo for tulip. I didn't put it into other drivers when someone (at the Summit?) pointe
I'm not sure I understand your comment. When you say "But it does seem to me that transitions to state (c) above are problematic just now." are you saying you don't think that we are currently able t