Open Karry opened 6 years ago
I agree this mapping is a problem.
I think it's not great, that the integer range of libnl errors overlaps with errno, and that some errno are coerced to libnl errors.
I think all operations that fail, should also try to preserve the errno that cause the failure. In your case, what's the callstack from entry into libnl to where the errno was received?
To be honest, I don't know. Libnl entry was nl_recvmsgs_default
, it fails with return code NLE_NOMEM
(5) and errno ENOSYS (38 - Function not implemented). This is everything that we known from our logs. This failure is not reproducible...
Hi.
I have question, why two different
errno
codes are mapped to single libnl error code? There is no possibility to distinguish betweenENOBUFS
(that is not fatal for us) andENOMEM
. Both are mapped toNLE_NOMEM
code: https://github.com/thom311/libnl/blob/master/lib/error.c#L103In our experiments, we found out that we can't rely on
errno
after some libnl calls when it is compiled with Musl libc - some internal Musl/libc functions setup errno to 38 (Function not implemented) sometimes...