On Tue, Jun 17, 2008 at 01:24:25PM -0400, Alan Stern wrote:

On Tue, 17 Jun 2008, Dmitry Torokhov wrote:

quoted

On Tue, Jun 17, 2008 at 10:39:15AM -0400, Alan Stern wrote:

quoted

On Tue, 17 Jun 2008, Dmitry Torokhov wrote:

quoted

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