[lkml]   [2002]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Patch, forward release() return values to the close() call
> 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.

> > 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?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:25    [W:0.093 / U:8.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site