Am Donnerstag 10 November 2005 00:49 schrieb Jamal Hadi Salim: > > 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 think I'd been using a Commodore Amiga when SLIP was en vogue ;-) > I would suspect it should still work > the same way. For PPP one thing has changed: Routes are not pointing to a dummy device anymore, but to the real PPP device. Incoming packets are forwarded to pppd while no dialup (*) connection exists. The PPP driver even has a private flag indicating that operational state. That behaviour is quite nice because it presents a stable device to the routing dae^W^W^W userspace. (*) Even though dialup can mean ill things like a PPPOE session nowaydays ;-) > > 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? We have agreed that it can't be the device driver. We would need to use the protocol handling code, e.g. ethtool for ethernet, instead. For both bitfields and a combined operstate, that would require defining clean semantics for every protocol - either which operstate transitions are allowed by userspace or under which conditions userspace may change the dormant flag. So if we avoid the complexity of my userspace override solution, we will add complexity to the protocol handlers. Again, it's not that far away, see WLANs. 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
