lkml.org 
[lkml]   [1999]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: IFF_UP vs IFF_RUNNING


On Fri, 9 Jul 1999, George Bonser wrote:

> On Fri, 9 Jul 1999, Gergely Madarasz wrote:
>
> > I have already fixed the syncppp driver (and dev.c to keep IFF_RUNNING
> > consistent) when integrating the comx drivers. You can download the full
> > patch from
> > ftp://ftp.itc.hu/pub/linux/v2.2/very_experimental
> >
> > Greg
>
> I do not think it is a good idea to do this. I think up and ruinning are
> two separate issues. Example is with the beowulf channel bonding. Imagine
> 4 network interfaces bonded together. Now one of them looses the link.
> IFF_RUNNING should drop and it should be excluded from round-robin packet
> load balancing. If the link comes back up when some luser plugs the patch
> cord back in, IFF_RUNNING should come back up and the interface should be
> placed back into use.
>
> If IF_UP drops, that means the interface has been taken out of service and
> is not to be used under any circumstances ... I do not care what the state
> of IFF_RUNNING is, it is down (!up) so do not use it, period. Also, if the
> link drops I might not want the interface marked down it if is a transient
> faliure (reset a machine at the other end of the link) because I may have
> to manually ifconfig up the interface in order to use it again or some
> routing protocol may tell the world that an interface went away causing
> all kinds of discovery/convergence problems for minor troubles that go
> away. I do not want to cause routing storms because I am moving some
> cables around.
>
> IFF_RUNNING really should not be set when IF_UP is set because it might
> not be actually running! That should be set by code somewhere else that
> checks the status of the link.
>
> They are two different flags meaning two different things. If you are to
> place them into lock-step, then you might as well get rid of one of them
> altogether.

I think you didn't understand it. My patch against syncppp.c (and
net/core/dev.c) allows IFF_RUNNING to be set by the link protocol driver,
while IFF_UP is set by dev.c only. The reason for setting them together in
dev.c is that it should be compatible with the current way of things, when
IFF_RUNNING was set exacly when IFF_UP was set. My patch to syncppp.c
resets IFF_RUNNING when open and sets it only when the link protocol is
up. So it does exactly the thing you are talking about.

Greg


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.078 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site