Am Montag 07 November 2005 22:04 schrieb Thomas Graf: > > As the kernel maintains this connected route, userspace is IMHO not > > responsible. Quagga could add its routes with a higher metric > > (administrative distance in cisco terms), kernel should use them as soon > > as the connected route becomes unavailable due to carrier failure (or > > dormant for wireless interfaces). > > Then how are you going to implement OSPF which has its own link state > detection? It's basically the same just that checking the carrier is > a very weak solution.
What do you mean with OSPF link state detection? That a router and the (backup) designated router of a network must see each others hello before they exchange routing information? This has nothing to do with the question whether the kernel uses a kernel created route pointing to the oper down interface or not. > The routes, especially the local routes, must > exist while there is no carrier. I don't want the kernel to remove these routes, that would be broken. I want them be marked as inactive or unusable and being ignored by the routing decision while in this state. But maybe such a behaviour change should be configurable. > I think this is a very weak excuse to move something into the kernel > that can exist in userspace. Even then, the kernel creates this connected route implicitely when the interface is brought admin up, and is therefore responsible for it. Obviously we disagree here. > I'm not sure about what exactly you're argueing. Using a char for the > operational state may imply bit operations on some architectures. Ok, you got that point. > There goes your atomicity. dev->flags is certainly not protected by > dev_base_lock, I'm not even sure if the rtnl semaphore is acquired for > all write accesses to dev->flags. dev->flags is, look f.e. at dev_ioctl(); dev->state is not. But beside a short locking howto in core/dev.c, this is really not very well documented. May be this is the reason why some stuff in dev.c does not look totally race free ;-) > So you mean we should not follow the RFC in this case? What operational > status would it be then? OPER_UNKNOWN? Well actually I meant you shouldn't have this difference in your dev_oper_state() function: > + if (!netif_running(dev)) > + return IF_OPER_DOWN; > + > + if (!netif_carrier_ok(dev)) > + return IF_OPER_LOWERLAYERDOWN; Both should be IF_OPER_DOWN then. > > Can't see that requirement from RFC, and devices are normally initialized > > in their open()-"methods". > > It's an SNMP RFC, it's not supposed to tell us how to manage interface > states in the kernel. The carrier state is event driven, which means > that when we don't memorize this information while we announce the > interface as down we'd have to ask the drivers about the carrier state > when we put it up again which is just non-sense. OTOH, (ethernet) drivers usually check link state when they are opened, so there should be a valid operstate after dev->open() returns. Anyway, there is indeed no reason to force operstate to some value from core, beside setting it to unknown when struct net_device is allocated. Stefan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
