Messages in this thread | | | Date | Sat, 10 Jul 1999 16:40:48 +0200 (MET DST) | From | Gergely Madarasz <> | Subject | Re: 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/
| |