Re: Role of close() in struct input_dev

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

On Tue, Jun 19, 2001 at 09:01:30PM +0200, Johann Deneux wrote:
> Hi !
> 
> I am trying to clean up my addition about multiple open-with-write-access.
> My first idea was to use a flag, only_one_writer in struct evdev, and then
> perform the necessay checks in evdev_open and evdev_release.
> 
> Vojtech suggested that we add a parameter to input_dev::open and pass
> that parameter to device drivers and let them decide. This would indeed
> allow for more flexibility.
> I thought that input_dev::close should be modified the same way.
> 
> I tried to implement this, and while doing so, I noticed that it could be
> that input_dev::open and input_dev::close are not called the same number
> of times. This may or may not be a problem, I don't know.
> 
> Here is a sample scenario:
> 1. Application 1 opens /dev/input/event0
> 2. Application 2 opens /dev/input/event0 (nothing forbids that)
> 3. evdev_disconnect is called (usb device is unplugged, input_attach is
> kiled...)
> 
> Steps 1 and 2 call input_dev::open, step 3 calls input_dev::close.

No. As it is now (or was the last time I remember it), step 2 doesn't
call input_dev->open.

> Now the question is: What is the role of input_dev::close/open ?
> Are they meant as "init/deinit the device" or "establish/break connection
> with processes" (or a mix of both) ?

Originally it was intended to init/deinit the device so that it can
have the USB IRQ running only when the device is used, same with
joysticks, which eat a considerable amount of CPU while polling.

> I would vote for the second possibility.

It's beginning to sound more reasonable, though I think there will be
problems arising with it.

> By the way, if you add a step 4 to my scenario:
> 4. Application 1 or 2 writes to /dev/input/event0
> then the application segfaults, and dmesg tells me someone tried to
> dereference a NULL pointer.

Interesting, gotta try ...

-- 
Vojtech Pavlik
SuSE Labs