public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brown <dave@codewhore.org>
To: Axel Kittenberger <Axel.Kittenberger@maxxio.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Patch, forward release() return values to the close() call
Date: Mon, 25 Mar 2002 08:33:50 -0500	[thread overview]
Message-ID: <20020325083350.A16464@codewhore.org> (raw)
In-Reply-To: <200203210747.IAA25949@merlin.gams.co.at> <200203220758.IAA09819@merlin.gams.co.at> <20020322085143.A16251@codewhore.org> <200203250950.KAA23657@merlin.gams.co.at>

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

  reply	other threads:[~2002-03-25 13:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-21  7:47 Patch, forward release() return values to the close() call Axel Kittenberger
2002-03-21  8:13 ` Jeff Garzik
2002-03-21 16:32   ` David Brown
2002-03-22  7:58     ` Axel Kittenberger
2002-03-22 13:51       ` David Brown
2002-03-25  9:50         ` Axel Kittenberger
2002-03-25 13:33           ` David Brown [this message]
2002-03-26  8:52             ` Axel Kittenberger
2002-03-21  8:21 ` Jeff Garzik
2002-03-21  8:27 ` Jeff Garzik
2002-03-21  9:10   ` Oliver Neukum
2002-03-21  9:18     ` Jeff Garzik
2002-03-21 10:14       ` Oliver.Neukum
     [not found] <mailman.1016697001.29134.linux-kernel2news@redhat.com>
     [not found] ` <200203211845.g2LIjTu22218@devserv.devel.redhat.com>
2002-03-22  8:06   ` Axel Kittenberger
2002-03-22  8:53     ` Pete Zaitcev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020325083350.A16464@codewhore.org \
    --to=dave@codewhore.org \
    --cc=Axel.Kittenberger@maxxio.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox