Am Mittwoch, den 16.09.2020, 20:14 +0900 schrieb Tetsuo Handa: > On 2020/09/16 19:18, Oliver Neukum wrote: > > Am Dienstag, den 15.09.2020, 19:30 +0900 schrieb Tetsuo Handa: > > > On 2020/09/15 18:14, Oliver Neukum wrote > > > > Is there something we can do in flush()? > > > > > > I consider that wdm_flush() is a wrong place to return an error. It is possible that > > > > I am afraid that is a basic problem we need to resolve. As I understand > > it, flush() as a method exists precisely to report errors. Otherwise > > you could implement it in release(). But this is not called for every > > close(). > > I think fsync() or ioctl() is a better method for reporting errors. Very well, I am implementing fsync(). However, I must say that the very existance of fsync() tells us that write() is not expected to push data out to devices and hence report results. > Whether N'th write() request succeeded remains unknown until (N+1)'th > write() request or close() request is issued? That sounds a strange design. Welcome to the world of Unix. This is necessary if you want to block as rarely as possible. > If there is nothing more to write(), how userspace process knows whether > N'th write() request succeeded? Wait for writability using poll() ? Technically fsync(). poll() will tell you that you can write again. That is a related but different concept. > What is the purpose of sending the error to the userspace process via write() or close()? Yes. However to do so, user space must be running. That the death of a process interferes with error handling is independent from that. > And I think that wdm_flush() is a strange interface for reporting the error. Well, POSIX is what it is.The close() syscall is supposed to return errors. Hence flush() must report them. Regards Oliver
