We do not define the XSI STREAMS errors that are defined in NetBSD, Linux and illumos:
Of course no one cares about XSI STREAMS, but e.g. drivers originating from Linux have (ab)used ETIME to mean whatever arbitrary timeout they wanted.
Currently, we have #define ETIME ETIMEDOUT in LinuxKPI (and cddl/contrib/opensolaris/uts/common/fs/zfs/zcp.c).
The most notable drivers that rely on this are DRM/KMS graphics drivers. So currently, Mesa has to do the #define ETIME ETIMEDOUT thing too, e.g.:
This is pretty bad, and Mesa upstream does not want to do that.
We need to either #define ETIME ETIMEDOUT in errno.h, or define it as a new error number and get rid of #define ETIME ETIMEDOUT everywhere. The latter is more "proper" (same distinction between the two as on other systems), but slightly more painful (-CURRENT users would have to upgrade both kernel/drm-next-kmod AND Mesa at the same time once).
Other userland software doesn't compile for this reason, e.g. https://github.com/IAIK/meltdown/issues/14
The "solution" there was:
#define ETIME 62
which seems strictly worse than either of the two options you describe.
Debian Code Search returns 3470 (Debian) packages referencing ETIME, https://codesearch.debian.net/search?q=ETIME
Some of these are going to cause grief if we start defining ETIME, e.g.:
# define ETIME ETIMEDOUT
# include <pthread.h>
# include <sys/sem.h>
so it seems like the first thing we'll want to do is perform a ports exp-run with ETIME defined
(In reply to Ed Maste from comment #1)
Yeah, the ones that define it to ETIMEDOUT when __FreeBSD__ is defined, as opposed to when ETIME is undefined, are going to cause the most pain with the second option.