>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
Do you see how many places call fput() ? Are you going to audit
__all__ those paths and prove to us that changing the semantics of
close(2) in Linux doesn't break things in the kernel or in userland?
Your driver is buggy, if it thinks it can fail f_op->release.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/