* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-09 22:02 > My main concern here are dial on demand interfaces. Routes pointing to them > must be considered even if the interface is !OPER_UP. Routes pointing to > "permanent" interfaces in !OPER_UP should not.
Right, we do need a dormant state with all static routes enabled. > If we drop the OPER_DORMANTL3*-states, we might later define a flag that > marks > a route as permanent (stays when interface is !OPER_UP), as opposed to a > transient route that is removed/deactivated during !OPER_UP. Honestly if we'd go this way I'd favour giving responsibily of deleting and adding routes to userspace in this case. That is a philosophical thing though I think. > However, L3 > would lose the possibility to differenciate between a dialer that can dial > and one that can't. I don't consider this limitation too bad, but it would be > there and stay for a while. Could you elaborate on this, I'm not quite sure if I understand. > > From an adjacency perspective this is no different than the kernel > > resolving arp request and then obsoleting it when the neighbor fails > > to respond. If arp is run in user space however, it will be upto user > > space to take care of this. > > Sorry, I don't get this in this context. I think what jamal means is that because the kernel adds the routes, the kernel should also be responsible to "expire" them when the interface loses the carrier. > Currently, IFF_RUNNING is created out of dev->state that is *not* protected > by > any lock as the driver can change it from interrupts. Instead, atomic bit > operations are used. If we allow userspace to write into operstate - either > into independant bits that Krzysztof suggests or into my operstate_kernel > field - we would have races. I'm sorry to come up with this again but I haven't seen your solution to the problem that your implementation cannot keep track of the carrier state while in operational state is "down". Do we gain anything by using the state model rather than just representing it by deriving it form the flag based state? > So based on the transitions we need I had the idea that userspace can put an > upper limit on the operstate reported using the user override field. I don't think it's bad but userspace only has to be able to trigger dormant->up and up->dormant, no? So couldn't we solve this in an easier way with just a flag? > However, > this is still not race free. We have a 802.1X protected device that cannot go > from DOWN->UP, only from DOWN->DORMANT because supplicant needs to run. > Depending on system load, the driver can report an UP->DOWN->UP flap before > the supplicant gets a chance to run and change user override to DORMANT. > That's why I've defined a semantic that allows kernel to lower the user > override field when a link state notification is sent. I think we agree on these semantics, the question is whether we need a state for this or if the IFF_WAIT flag I put into my patch is sufficient. > As Thomas pointed out, this is still not perfect if the driver produces > events > too fast for linkwatch workqueue, but that's an implementation detail and not > a design flaw. Right. > If Thomas is right and byte accesses are not atomic "enough" on some > platforms, maybe I even have to use atomic_t. Just use int as long as you don't need atomic dec_and_test() etc. - 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
