On Wed, 2005-09-11 at 22:02 +0100, Stefan Rompf wrote: > Am Mittwoch 09 November 2005 21:13 schrieb Jamal Hadi Salim:
> > 1) In regards to the connected routes: > > - I would agree that there is need to do something about them - but i > > dont think those extra L3* states are the answer. So Stefan, we need to > > kill the L3* thingy IMO. > > 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. > > 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. 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. > Historically we point such routes to the dummy device. Remember diald and good ole SLIP dial on demand? I would suspect it should still work the same way. Actually, probably use a blackhole route which will swallow such packets alive instead of dummy. i.e when link is down for such a device you (whoever is configuring) makes the route a blackhole. And when its operationaly up it is made point to the correct device. In other words I think this is the responsibility of the link manager. > 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. > But if you made the driver the proxy for making the state transitions we should be fine, no? > 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. 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. > > 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. > Same comment as above in regards to using driver as proxy. You already (I thought) take good care of link flaps. > > 4) it would probably be a good idea to use a u8 instead of uchar for the > > oper flags > > If Thomas is right and byte accesses are not atomic "enough" on some > platforms, maybe I even have to use atomic_t. I don't want to take > dev_base_lock for a write access in case a device goes berzerk. (Without also > taking rtnl which can't be done from an interrupt it would be against the > locking semantics defined in net/core/dev.c anyway) > Ok - this is something i am gonna let you and Thomas settle. It seems to be an issue of picking half a dozen of one or 6 of the other. cheers, jamal - 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
