netdev
[Top] [All Lists]

Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified

To: davem@xxxxxxxxxx
Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified
From: "Janice Girouard" <girouard@xxxxxxxxxx>
Date: Fri, 4 May 2001 12:07:56 -0400
Cc: c729953@xxxxxxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
Importance: Normal
Sender: owner-netdev@xxxxxxxxxxx
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 link_status_changed.

    * sis990.c (pci fast ethernet) set's this flag when the
       link status changes
     * via-rhine.c set's this flag to indicate link status changes
     * the device driver for the 4 port serial controller i2o_lan.c sets
       this initially, however never shows state changes
     * i2o_lan.c uses this flag uses this flag to indicate if the
        link is up or down.

The error handling of networks cards is exactly the problem I'm
trying to solve without having a tulip_timer routine for each driver.


__________________________________________________________________
Janice Girouard
girouard@xxxxxxxxxx
512-838-7981


---------------------- Forwarded by Janice Girouard/Austin/IBM on
04/05/2001 10:31 ---------------------------

Roger Venning <c729953@xxxxxxxxxxxxxxxxxxxxxxxxx> on 04/05/2001 01:07:24

To:   "David S. Miller" <davem@xxxxxxxxxx>
cc:   Janice Girouard/Austin/IBM@IBMUS, netdev@xxxxxxxxxxx
Subject:  Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified



On Thu, 3 May 2001, David S. Miller wrote:

>
<snip>
> 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
> interested in.  It would be meaningless for the notifiers to run
> every time I yank my ethernet cable out of the card on my machine :-)

(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 little. Considering the case with the machine has
multiple network interfaces, and a mobile IP (RFC2002 and
friends) capability, this kind of notification is crucial to smoothly
transferring traffic onto other available interfaces (think mobile pda
with ethernet & wide area cellular data). This is just one instance of
'middleware' style applications that would prefer not to poll this kind of
state.

Roger.

>
> Later,
> David S. Miller
> davem@xxxxxxxxxx
>

--
Roger Venning - Technologist - Telstra Research Laboratories

          For a successful technology, reality must take
          precedence over public relations, for Nature
          cannot be fooled.                 Richard Feynman





<Prev in Thread] Current Thread [Next in Thread>