> From: "Theo de Raadt" <deraadt@openbsd.org>
> Date: Tue, 15 Jul 2025 12:45:25 -0600
> 
> The vague POSIX number/name for EREMOTE has nothing to do with the
> error condition in inteldrm(4).
> 
> It has to do with path handling, probably NFS, it is very unclear.
> 
> I suspect what's going on here is the driver wants to provide a unique
> error number for a failure condition which will print a different
> (obscure, but different) error message to a user or an unknown test
> program.  So they chose EREMOTE, rather than ENOMEDIUM or EBADRPC or
> 37373.
> 
> We could document it, but that changes nothing.  POSIX has become
> infected with the idea of copying errno names from various systems
> without clearly identifing which operations return it in which
> conditions, and this has turned into a trashfire where many system calls
> can return pretty much any error value, and applications can only do
> specific behaviour for a handful of errnos, the rest they either consider
> (all?) fatal or (all?) ignorable.
> 
> That's the state of the art.  <SHRUG>

To be honest, I think this is more an issue with folks just looking at
the names of the errno values and picking the one that feel
appropriate without consulting POSIX or our man pages to determine
what they really make.

That certainly is the feeling I get whenever I look at Linux code.
And it also something we're guilty of ourselves.