Re: Role of close() in struct input_dev

[Vojtech P. <vo...@su...>]

On Tue, Jun 19, 2001 at 11:41:14PM +0200, Johann Deneux wrote:
> On Tue, 19 Jun 2001, James Simmons wrote:
> 
> > 
> > > There are parts of evdev functions called by userland, and other parts
> > > called by other modules. Namely, evdev_disconnect can be called by serio,
> > > for example.
> > > The problem is still there: I would expect
> > > input_open_device/input_close_devise to be called at least the same
> > > number of times (perhaps we should even take care of the order).
> > 
> > Both would be called the same number of time. Well I hope. The order is
> > what matters. 
> 
> After further checks, yes they actually are called the same number of
> times.
> In fact, I realised the driver doesn't really know when a process does an
> open(). Indeed, input_open_device is called only when the first process
> opens the device, and input_close_device when all processes closed it.
> I would however need a function to be called every time a process accesses
> an i-force device.
> Two solutions:
> 
> - I modify the existing input_{open,close}_device
> Frankly, I don't really like the fact that evdev can be kfreed both by
> evdev_disconnect and evdev_connect. Furthermore, the choice is done after

You meant evdev_disconnect and evdev_release, right?

> the value of evdev->exist, whose access is not protected (possible bug if
> the last process releases the device while the device is being
> disconnected, on a smp machine (weird case, though))

Yes, it's most likely not completely SMP safe. It's simple, though - as
long as the device is connetced *or* is opened, we need struct evdev.

> - I add new callbacks to input_dev
> I need to make modifications to this struct, and having two different kind
> of open functions may be confusing. If driver writers need to make a
> distinction between the first open(), and subsequent open(), they can
> handle it themselves.
> 
> Anyway, it seems we have to check evdev->exist before doing anything in
> evdev_{ioctl,read,write...}, I guess this is what caused the oops I got.

Most likely, yes. read() should be fine, though, as it doesn't do
anything with the device.

-- 
Vojtech Pavlik
SuSE Labs