> > What about calls arriving while the shutdown is in progress? > > Some drivers might be able to handle them and other drivers > > might not. > > Do they need to handle them? Up to a point yes. Simply because the tty layer close helpers call back into the driver in order to - flush any pending data - handle any line discipline shutdown - fix up the carrier state > > What about calls that were already in progress before the > > shutdown started? To synchronize with them would require > > taking the mutex on each call or maybe using some form of > > RCU. Can we afford to do this? Or should we declare that You can't. The lock on the tty port lookup and reference in the receive path is marginal enough with high speed 3G modems, which is why I had moving the queues to the tty_port in the todo list. Plus the calls are all blocking anyway and some of them have a lifetime over the hardware activity lifetime (see hangup behaviour for an example) > > the TTY core is responsible for these things? > > I am very much in favor of dropping that to the tty layer. The tty core was slowly learning these things but you can't just break every serial driver. That work has now stopped midflow however and there are no plans I know of for anyone to do serious further work on it, except the rather nice work Alan Stern has done on USB. You also can't move them up the tty stack without having full exclusion between all the events you want further up the stack which is basically impossible to achieve in the short/medium term. You can probably do it at the USB level and then when we get a new tty maintainer perhaps do the same for the other 30 odd drivers and eventually propogate it upwards. Anyway tty has no maintainer so if you want to move it to tty, you get to maintain the tty layer and fix all the other drivers to work with your interface changes. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
