Hi,
since the SSSD development started, the codebase used only error codes
from the standard errno range (see man errno.h). Recently it has became
apparent that it's not really sufficient -- the errno codes are too tied
to glibc interface and system calls and do not really reflect what is
going on in the SSSD. Quite often, we would misuse "EIO" or "EFAULT"
for
"something is wrong".
There are cases where we want to accuratelly report the particular error
code to an external interface (such as pam_sss). Previously we would just
special case some errno codes, but that turned out to be too buggy and
hard to follow. See upstream bugs like #1310 or #1699 for an example.
To solve this issue, Simo proposed introducing an internal range or SSSD
specific error codes:
https://lists.fedorahosted.org/pipermail/sssd-devel/2013-January/013368.html
https://lists.fedorahosted.org/pipermail/sssd-devel/2013-January/013371.html
https://lists.fedorahosted.org/pipermail/sssd-devel/2013-January/013370.html
https://lists.fedorahosted.org/pipermail/sssd-devel/2013-January/013369.html
https://lists.fedorahosted.org/pipermail/sssd-devel/2013-January/013372.html
I think his patches are very nice in general. I reviewed the patches in
person this weekend on
http://devconf.cz and when I run some more tests
I'd like to push them.
To sum up our discussion for the other developers, here are some guidelies
to follow. In general, after the patches are pushed, the new code should
use the SSSD specific error codes, not errno internally.
* If the current error codes do not fit, the developer should
introduce new ones. The new error codes should be specifically
called out in the commit message or even split into a separate
patch as appropriate. In general, the error codes should converge
over time to a stable set that wouldn't grow any more.
* When introducing new error codes, the developer should make sure
that consumers of the interface being introduced or converted
does not special case some old errno-codes (we often
special-case EAGAIN to denote "request still in progress" for
example)
* the error codes would not be split into any ranges. If the
caller needs to check N error codes, it should check N separate
error codes (or refactored)
Please raise any concerns you might have over the plan.