On Tue, Jun 17, 2008 at 01:24:25PM -0400, Alan Stern wrote: > On Tue, 17 Jun 2008, Dmitry Torokhov wrote: > > > On Tue, Jun 17, 2008 at 10:39:15AM -0400, Alan Stern wrote: > > > On Tue, 17 Jun 2008, Dmitry Torokhov wrote: > > > > > > > Input core only protects open() and close(); connect() and > > > > disconnect() belong to respective bus's implementation the device is > > > > sitting on and input core has no authority over it. > > > > > > What about open vs. unregister? The input core must have some > > > protection for those two. > > > > > > > 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? > > (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(). -- Dmitry -- 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
