>Here goes my liitle patchy, once again :o)
>
>Whats it's about?
>
>When close()ing an charcter device one expects the return value of the
>charcter drivers release() call to be forwarded to the close() called in
>userspace. However thats not the case, the kernel swallows the release()
>value, and always returns 0 to the userspace's close(). (tha char drivers
>release() function is called in fput() as it would have a void return value)
>
>It may sound weired at first but there are actually device drivers than can
>fail on close(), in my case it's a driver to program a LCA, the userspace
>application signals end of data by closing the device, the driver finalizes
>the download, and the LCA reports if it has accepted it's new program, if not
>close() should return a non-zero value, indicating the operation did not
>complete successfully.
>
Note also that the Single Unix Specification v3 says that the state of
the filedes is undefined. If your applications are relying on such
fail-on-close(2) behavior that keeps the file descriptor completely
intact, they are non-standard at best, buggy at worst.
Jeff
-
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/