Hi, This is a topic we briefly discussed with Jakub J. during our last two-person hangout. tl;dr: libc should not define the set of usable error codes and their semantics, individual protocols should.
The rationale for this proposal is two-fold. Historically, the error codes are not "generic" errors, but UNIX kernel errors, and as such they had well-defined use and semantics - the kernel is a single unit, and every code has a precise meaning, captured by the kernel documentation. If some new error condition arises in the kernel code, a new code is added to the userspace library. Our use of error codes significantly departs from the original. We have actually redefined some (like ENOENT), and we use libc error codes as a sort of catch-all in IPC communication. Also, our error code numbers are negative (in conflict with standards). Furthermore, some code does not use the errno to pass errors, in favor of in-band error reporting (as seen in VFS protocol - positive values are results, negative values are errors). But some code (perhaps older) does still use errno, some use it inconsistently, and some code even incorrectly assumes the library uses errno (as seen in bdsh for example, or stdio implementation). >From the practical standpoint, having each IPC protocol (and the corresponding library) specify their own errors would create a much cleaner interface, better specification, predictability, and would eliminate the need to pollute libc with protocol-specific errors, or using EINVAL for all errors that just don't fit. "Wait a second," you say, " some error codes still have special meaning in the kernel." Well, you are correct, and such error codes should stay in the kernel, never to be returned to client by server code, but only ever by the kernel. Anecdotal evidence for that is that for example EPARTY is a quite attractive error code to use for all sorts of failures, but it is used in kernel under special circumstances, which means returning it from the server obscures its meaning. Another thing to consider is that there are servers that act as switchboards for other servers (like VFS). In some cases, passing errors as-is is undesirable, as the protocols can have a different idea of what some error means, and because you could pass a special error like EHANGUP, which is interpreted by the kernel. Explicit translation of errors between protocols (easily done using an array) would solve all such problems. To finish this, here is what I propose: - Fix all non-standard aspects of <errno.h>. - Drop all use of <errno.h> in non-standard functions. - Define kernel error codes (IPC, MM, threads, ...) in a relevant header, possibly along with a very small set of highly-generic errors like "invalid method arguments". - Define protocol-specific error codes the same way method codes are defined. - Where necessary, translate error codes explicitly. Any thoughts? -- Jirka Z.
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
