On Tue, 17 Jun 2008, Dmitry Torokhov wrote: > > > input_unregister_device() sets dev->going_away at the very beginning > > > and input_open_device() will fail with -ENODEV when trying to open such > > > devices. dev->going_away (among other things) is protected by > > > dev->mutex. > > > > > > Do you see any issues with this scheme? > > > > It depends on how much code is protected by dev->mutex. > > > > The real issue involving open vs. unregister comes down to this. It > > should not be possible for either: > > > > (1) an input_unregister_device() call to return while an > > input_open_device() call is in progress; or > > Theoretically it is possible with wierd scheduling i guess. What I can > guarantee is that either input_open_device() fails or if it succeeds > input_close_device() will be called for the device at some point but > before input_unregister_device() returns. Does this help? Yes, that's right. I expressed myself poorly above; what I meant was that it should be impossible for input_unregister_device() to return while a call to an input driver's open method is in progress. Since the entire method call is protected by dev->mutex, this is guaranteed. > > > > (2) an input_open_device() call to be made after > > input_unregister_device() has returned. > > As soon as input_unregister_device() starts executing > input_open_device() will start failing. Additionally, when > unregistering a device we forcefully disconnect all attached input > handlers so by the time input_unregister_device() is finished there > should be noone who can call input_open_device(). Again, what I meant was that the open method should never be called after input_unregister_device() has returned, and again this is guaranteed. So it all looks good from the point of view of an input device driver. The driver knows that after it has called input_unregister_device(), the input core cannot have any threads for that device executing inside the driver. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
