lkml.org 
[lkml]   [2002]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Patch, forward release() return values to the close() call
    Date
    > 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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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