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: Fri, 22 Mar 2002 08:51:43 -0500	[thread overview]
Message-ID: <20020322085143.A16251@codewhore.org> (raw)
In-Reply-To: <200203210747.IAA25949@merlin.gams.co.at> <3C999633.2060104@mandrakesoft.com> <20020321113201.A26882@codewhore.org> <200203220758.IAA09819@merlin.gams.co.at>

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

On Fri, Mar 22, 2002 at 08:58:02AM +0100, Axel Kittenberger wrote:
> > Forgive me if I'm not completely understanding this, but isn't release()
> > only called when the refcount of the file structure drops to zero? e.g.:
> >
> >   [18]Note that release isn't invoked every time a process calls close.
> >   Whenever a file structure is shared (for example, after a fork or a
> >   dup), release won't be invoked until all copies are closed. If you need
> >   to flush pending data when any copy is closed, you should implement the
> >   flush method.
> 
> Oh that might be, however in my case the device is exclusivly locked, so it 
> doesn't matter that much, since there can be only one writer.
> 
> To explain what it actually is, it's a driver to program a LCA chip, an 
> userspace opens the device, writes the program for the LCA, and closes the 
> device. The driver itself can not understand the file format transmitted 
> trough it, and has so no chance to know where the supposed end of stream is 
> until the userspace closes the device. At close() it let's the LCA go, and 
> looks if it's starting up, if so it has accpeted it's program, if not the 
> file was not a valid image or the LCA might be damaged, and this error 
> condition should be signaled.
> 
> Programming a LCA simply works then from the shell like in example this:
> $> cp my-lca-image /dev/lca || echo "LCA failure :("
> 
> Where cp fails if the lca has not accepted it's image.
> 
> flush() can also be called in middle of stream, and is not a good indication 
> for an end of stream. 

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.

> 
> > > Your driver is buggy, if it thinks it can fail f_op->release.
> 
> If this is would be really (always) true, wouldn't it at least be better to 
> have the release() prototype with a void return value?

That wasn't me, that was Jeff. :)


- Dave
  dave@codewhore.org

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

  reply	other threads:[~2002-03-22 13:54 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 [this message]
2002-03-25  9:50         ` Axel Kittenberger
2002-03-25 13:33           ` David Brown
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=20020322085143.A16251@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