On 2024-07-30 08:47, Christoph Hellwig wrote:
On Mon, Jul 29, 2024 at 09:23:22PM +0200, Florian Weimer wrote:
Anything that's not EOPNOTSUPP will do. EMEDIUMTYPE or ENOTBLK might do
it. Any of the many STREAMS error codes could also be re-used quite
safely because Linux doesn't do STREAMS.
Huh? EOPNOTSUP(P) is the standard error code in Posix for operation
not supported, and clearly documented as such in the Linux man page
(for musl). A totally random new error code doesn't really help us.
It would help glibc distinguish the following cases:
A. file systems whose internal structure supports the semantics of
posix_fallocate, and where user-mode code can approximate those
semantics by writing zeros, but where that feature has not been
implemented in the kernel's file system code so the system call
currently fails with EOPNOTSUPP.
B. file systems whose internal structure cannot support the semantics of
posix_fallocate and you cannot approximate them, and where the system
call currently fails with EOPNOTSUPP.
Florian is proposing that different error numbers be returned for (A) vs
(B) so that glibc posix_fallocate can treat the cases differently.
If you remove the fallback code, applications need to be taught about
EOPNOTSUPP, so that doesn't really make a difference.
Portable software can't assume that posix_fallocate actually does
anything.
Of course, but this issue is about whether glibc posix_fallocate should
continue to work on type (A) file systems. It's understandable that
glibc maintainers would be reluctant to mess with that longstanding
behavior.
