Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 6 Jun 2003 14:43:17 -0700 | From | Mitchell Blank Jr <> | Subject | Re: [PATCH][ATM] use rtnl_{lock,unlock} during device operations (take 2) |
| |
Werner Almesberger wrote: > (It's different in the case of > SVCs, but they're managed by a user space demon. Besides, if > their device goes away, they die too.)
Yes, in theory it would be nice to have SVCs be able to reroute between interfaces, but we certainly don't have the infrastructure to do that now (and I doubt that they'll ever be a significant enough push to demand its development) To do that you'd need the kernel to look like a simple ATM switch and have atmsigd speak NNI to its neighbors (didn't someone have some code for this WAY back in the dark ages... but it had some unfortunate license issues... or am I remembering wrong?)
You still would have the the userspace-visible vcc pinned to a ATM device but it would just be a pseudo-device managed by the virtual switch. Then the switch would take care of how to route the SVC.
So in short I agree with you that the current method is best - it makes no operational sense to deactivate an ATM interface while there are still open VCs. Since VCs are intrinsically bound to a {dev,vpi,vci} tuple from userlands perspective they would be uselss if their dev disappeared (even if it reappeared later).
One thing I WOULD like to see is way to do something like "ifconfig up/down" on ATM devices (once the VCs are all down) instead of having all of the ATM cards with drivers automatically considered "up" like we currently do. Some types of interfaces (esp *DSL) have rather complicated procedures for setting up the interface and it would be nice to be able to control this explicitly. It'd be really useful to have a third state called "auto" which would bring it up when the first VCC is opened and down when the last is closed. Not only would this be great for DSL (since it would establish the DSL connection automatically when you run pppd or whatever) but it would be a sane "least surprise" default.
[Very vaguely related - it would also be nice to have a per-itf flag to require CAP_NET_BIND_SERVICE for all VCCs instead of just "vpi==0 && vci<ATM_NOT_RSV_VCI". In 99% of deployments there aren't any ATM-native apps running so you don't want users establishing random ATM vcs]
-Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |