>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/