Re: Role of close() in struct input_dev

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

On Wed, 20 Jun 2001, James Simmons wrote:

> 
> > 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.
> 
> Flush? This is new. How does a userland take advantage and does this
> function do what I think it does, flush all data stored for a file?

It's called by close(). And so is input_dev::release(). So what's the
difference, you may ask ?
flush() is called at every close(), release() only on the last
close(). That's what the doc says, which leaves a few questions open. I
will play with little programs to check how it exactly behaves.

> 
> > 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 ???
> 
> Only if it does free all the list elements for this particular device when
> close is called.
>  

We could use evdev_flush() to individually free every list element as it's
closed, and evdev_close() to free all the remaining ones (which should
not exist, btw, as they should have been freed by a evdev_flush())

> > 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)
> 
> Yeah it is misleading.

accept_process() would be better. input_accept_process() would be nice,
too, but it brakes the input_{something}_device "rule"

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