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