On 4/19/24 15:45, The 8472 wrote: > Syscalls have documentation. Errors and their semantics are part > of the documentation. If the kernel cannot actually provide > the documented semantics because it passes errors through without > sanitizing them then this should at least be documented > for each affected syscall. And that documentation is *different* depending on the platform. The clean vision you seem to have about errnos is not real. There are conventions... not strong contracts. I had this exact debate days ago about `link`. The claim that if link isn't supported by the OS FUSE should return EPERM. But this just isn't standard the way people think it is. Not on paper. And if a FUSE server wants to return EPERM then it can. I don't see why the kernel needs to get in the business of reading the mind of the server author. > > Proper API documentation and stability guarantees are important > so we can write robust software against them. > > Note that write(2) documents > > Other errors may occur, depending on the object connected to fd. > > close(2) has no such note. Your idea is laudable but not realistic. errnos are not even fully consistent across devices or filesystem. Yes, there are norms and some standards but they are not enforced by some central arbiter across all forms of *nix. > That does not mean userspace should be exposed to the entirety > of the mess. And in my opinion EIO is better than EBADF because > the former "merely" indicates that something went wrong relating > to a particular file. EBADF indicates that the file descriptor > table of the process may have been corrupted. "should"... but it is exposed to it. *Most* software doesn't even attempt to handle errors intelligently and just return the error up the stack blindly. EIO is about as generic as can be and I've seen it used many times as the "catch all" error making it meaningless. Further incentivizing client software to behave as they do... not paying attention. I will again point out that I've seen EXDEV treated like any random other error several times in my career by important pieces of software made by major vendors. > Will try. But the kernel should imo also do its part fulfilling its API > contract. Then you are barking up the wrong tree. This isn't an issue unique to FUSE. FUSE just makes it more obvious to you because anyone can write a FUSE server and return (almost) anything they want. > That it requires perhaps some thought to do it properly does not seem > sufficient to me to dismiss the request to provide a proper > abstraction boundary with reliable semantics that match its documentation. I simply don't see what you could do to "do it properly." I am trying to argue there is no such thing. And again it would require breaking every single FUSE server.
