On 19-04-2024 23:29, Antonio SJ Musumeci wrote:
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.
I'm writing to a linux mailing list, am I not? And referring to linux-specific
manpages, not the POSIX ones. The way the linux kernel chooses to pass
what FUSE sends to userspace is under its control.
I would like linux to adhere more closely to its own API contract or improve its
documentation.
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.
That seems hardly relevant to this case here.
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.
If other things can cause this too, then yes of course, a more general
solution would be fine too for my purposes.
Should I have written to another list? Or filed a report on bugzilla instead?
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.
I don't understand what would be broken here. In a previous mail you agreed
that FUSE servers have no business sending EBADF and should have a
bug filed against them. If that's the case then sanitizing problematic cases
should be ok.
The libfuse documentation even notes that servers should not assume errors
from flush get delivered to userspace.
