On Thu, 2005-10-11 at 01:10 +0100, Thomas Graf wrote: > * Jamal Hadi Salim <[EMAIL PROTECTED]> 2005-11-09 18:49 > > 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. > > This is not only about dial on demand but about "on demand" interfaces. > We need to have a route to the device so the driver/manager/whatever can > see the demand. If we disable routes on !IFF_RUNNING we don't have this > route and we never see the demand. That's where the solution of deleting > all routes upon carrier loss fails. >
Well, the arguement goes both ways actually ;-> By adding those routes the kernel _is_ making policy decisions. In the case of standard dial on demand (any that i have seen on linux at least), they typically have something along the lines of scripts that get invoked during different phases of the link negotiation. > > But if you made the driver the proxy for making the state transitions we > > should be fine, no? > > I would absolutely appreciate a solution where no driver has to be > changed, userspace should be able to put an interface to dormant state > without any support from the driver. nod - i said that hoping to get things out of the stalemate. But everyone seems to be agreeing this is a bad idea; in retrospect, it is a bad idea. 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
