netdev
[Top] [All Lists]

Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified

To: Janice Girouard <girouard@xxxxxxxxxx>, davem@xxxxxxxxxx
Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified
From: David Brownell <david-b@xxxxxxxxxxx>
Date: Fri, 04 May 2001 10:19:38 -0700
Cc: c729953@xxxxxxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
References: <OF026BFD4B.B0532368-ON85256A42.00553C77@raleigh.ibm.com>
Sender: owner-netdev@xxxxxxxxxxx
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 connected/usable (say, carrier present)
    (d) interface is "up"

I've noticed two issues automating transitions between
these states, such as by network hotplugging through user
mode policy agents.  Maybe someone has clean solutions
in the current 2.4 code; I've assumed these are 2.5 issues:

- Some hardware, such as USB-to-USB bridges (in the
  "usbnet" driver, 2.4.*-ac series), most naturally want
  to trigger hotplugging when entering state (c), rather
  than state (b) ... gotta look at the host on the other side
  and see what it says, before a user mode policy agent
  can go to (d) via static config, DHCP, or whatever.

    ISSUE: there's no event to report there!

- Some types of interface (at least ppp, ippp, isdn, plip, lo ...)
  seem to enter (d) before (b).

    ISSUE:  the network hotplug agents needed to special
    case those not to "ifup" on registration.

It's not clear to me that there is a single state model that all
network drivers follow.  Or: if there is one, it may be likely
that the events reported for hotplug are the wrong ones.

But it does seem to me that transitions to state (c) above
are problematic just now.

- Dave



----- Original Message ----- 
From: "Janice Girouard" <girouard@xxxxxxxxxx>
To: <davem@xxxxxxxxxx>
Cc: <c729953@xxxxxxxxxxxxxxxxxxxxxxxxx>; <netdev@xxxxxxxxxxx>
Sent: Friday, May 04, 2001 9:07 AM
Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified


> 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>