Messages in this thread | | | Date | Fri, 9 Jul 1999 19:10:45 -0700 (PDT) | From | George Bonser <> | Subject | Re: IFF_UP vs IFF_RUNNING |
| |
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.
- 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/
| |