On Mon, Mar 25, 2002 at 10:50:17AM +0100, Axel Kittenberger wrote:
>
> > This is me talking prior to having coffee, but Chapter 3 of the
> > Rubini/Corbet book says:
> >
> > The flush operation is invoked when a process closes its copy of a file
> > descriptor for a device; it should execute (and wait for) any outstanding
> > operations on the device. This must not be confused with the fsync
> > operation requested by user programs. Currently, flush is used only in the
> > network file system (NFS) code. If flush is NULL, it is simply not invoked.
> >
> > I guess it doesn't specifically say it's not called in midstream, but
> > it reads as if flush() is called on /only/ close(). I may test this
> > today, just for fun.
>
> Oh thats interesting, indeed, so the function name "flush" is just
> contra-intentional. Oxay I know now how I could have written this driver
> without patching the kernel.....
>
And FWIW, I tested this behavior with a dummy chardev and printks()
around open(), release, and flush(). flush() is indeed called only on
each close.
> Still the basic issue/idea is remaining. release() is defined as int return
> type, but everywhere it's called it's value is discarded. (except internally
> in "intermezzo" whatever that is)
>
> btw: blkdev_put() has int return type and seems to return correctly the
> return value from release()s for block devices, so I guess it would be the
> right thing for char devs to do also.
>
> The other way I would also see as okay is to state release() can't return
> anything senseful to anybody, bet then declare it as void return instead. But
> as the state is currently it's suboptimal from both views.
Agreed, but the question is which approach to use. :) Declaring it as void
sounds like it may involve a lot of driver fixup work.
Regards,
- Dave
dave@codewhore.org
This archive was generated by hypermail 2b29 : Sun Mar 31 2002 - 22:00:09 EST