`fi_errno` codes depend on implementation-defined macros
darrylabbate opened this issue · comments
Many of the core error codes defined in fi_errno.h
are mapped directly to their system-level counterparts defined in errno.h
. However, many of these are only available on Linux (e.g. EREMOTEIO
, EHOSTDOWN
). This leaves many of the core error codes unusable on other platforms.
Is there an intended workaround here? I don't think it's intended for providers to check the validity of an underlying core error code (e.g. #ifdef EREMOTEIO ...
), nor is it desirable to add extra logic for each supported platform (e.g. #ifdef _WIN32 ...
).
I don't believe there's a strict requirement for core error codes to map to something defined in errno.h
since there are proprietary core error codes >= 256:
libfabric/include/rdma/fi_errno.h
Lines 182 to 199 in 14aa24e
AFAICT, the only real benefit of the current implementation is the ability to reuse error messages from strerror(3)
. I'm concerned about the coupling with system-level error codes causing further cross-compatibility issues and establishing a de facto standard (i.e. FI_Exxx == Exxx
is a safe assumption)
CC:
The design is intentional. It not only allows reusing strerror(), but also avoids unnecessary error code translation when returning lower-level failures as OFI error.
On platforms that some of the error code definitions are missing, those missing codes should be defined in the corresponding osd.h
. See include/windows/osd.h
for some examples.
On platforms that some of the error code definitions are missing, those missing codes should be defined in the corresponding
osd.h
. Seeinclude/windows/osd.h
for some examples.
I see. So in the case where EREMOTEIO
(121) conflicts with ENOLINK
, it should just be defined as the next available "high number?"
libfabric/include/windows/osd.h
Lines 186 to 207 in 14aa24e
Yes.