Re: Role of close() in struct input_dev

[Johann D. <jo...@Do...>]

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

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


-- 
Johann Deneux
CS student at DoCS (www.docs.uu.se/~johannd) and
ESIL (www.esil.univ-mrs.fr/~jdeneux)