> 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 to mark transitions to state (c).
It's only a local marking. If Andi implements a mechanism
and first client for it, then that'll fix this issue.
> Or are you saying that we will never be able to mark transitions
> to state (c). I do think it's rather hit and miss right now.
I want to know exactly what that transition means, too.
Notice that I was putting this event in the context of a
state model for interfaces. Are all LINK_STATE flag
combinations legal? Which transitions trigger which
kinds of events (including hotplug reports)?
> But, it seems like this problem could be solved.
Yes, but it's not obvious to me what should be done.
- Dave
>
> Janice
>
> __________________________________________________________________
> Janice Girouard
> girouard@xxxxxxxxxx
> 512-838-7981
>
>
>
> David Brownell <david-b@xxxxxxxxxxx> on 04/05/2001 12:19:38
>
> To: Janice Girouard/Austin/IBM@IBMUS, davem@xxxxxxxxxx
> cc: c729953@xxxxxxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
> Subject: Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified
>
>
>
> 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
> >
> >
> >
> >
>
>
>
|