On Tue, 17 Jun 2008, Dmitry Torokhov wrote:

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

    (2) an input_open_device() call to be made after
	input_unregister_device() has returned.

Your description above suggests that (2) can never happen, but I can't
tell for sure.  And what about (1)?

Alan Stern