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
(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
--
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
