Re: Role of close() in struct input_dev

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

On Wed, 20 Jun 2001, Johann Deneux wrote:

> On Tue, 19 Jun 2001, James Simmons wrote:
> 
> > 
> > > 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.
> > 
> > Are you sure about that? For one thing each time you open /dev/mouse and
> > /dev/event both devices call input_open_device. This is a case where the
> > same hardware is opened twice. [...]
> 
> This is the case because from evdev and mousedev, the device is opened
> only once. What I meant was in the case where two processes or more 
> perform an open one after another. In that case, evdev and mousedev will
> call input_open_device only for the first process.
> Same thing for input_close_device. It's called only when evdev->open falls
> to zero (unless the device is disconnected).

Which is, I have just understood that, the wanted behavior. I mistook
release and flush. I added a new input_dev::flush() and 
input_flush_device() functions to do what I need.
Still, evdev_open can be called several times by a process. evdev_release
is called only once, when the last close on the device file is done
(according to "Linux 2.4 Internals"). Some list elements could then be
left unfreed, thus causing a memory leak. Or did I miss something ???

I also added a input_dev::accept() and input_accept_device() functions
(hmm, any idea about a better name ? the name misleads the reader into
thinking it's the device that gets accepted)
The goal of this function is to decide whether an open() call should be
accepted or not. I use this to prevent several processes from using
force-feedback at the same time.

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