Todd C. Miller <millert@openbsd.org> wrote:

> On Tue, 15 Jul 2025 12:45:25 -0600, "Theo de Raadt" wrote:
> 
> > The vague POSIX number/name for EREMOTE has nothing to do with the
> > error condition in inteldrm(4).
> 
> I didn't see it in IEEE Std 1003.1-2024, maybe I missed it?
> 
> > It has to do with path handling, probably NFS, it is very unclear.
> 
> It appears related to NFSERR_REMOTE (which is also 71) and comes
> from NFS v3 apparently.  So this originated with Solaris.  However,
> System V also defined EREMOTE as "Object is remote".  That appears
> to be the meaning that the drm code is expecting and is how it is
> documentd on Linux.
> 
> We could adopt the System V meaning of EREMOTE if we chose to do
> so.  We are not using it anywhere other than the drm code.

I guess my point is, looking at our manual page:

ERRORS
     ioctl() will fail if:

     [EBADF]            d is not a valid descriptor.

     [ENOTTY]           d is not associated with a character special device.

     [ENOTTY]           The specified request does not apply to the kind of
                        object that the descriptor d references.

     [EINVAL]           request or arg is not valid.

     [EFAULT]           arg points outside the process's allocated address
                        space.

Should this be:

       ioctl() will fail and set errno to just about any value in
       <sys/errno.h> because there are multiple intersecting shitshows
       lacking coordiantion.

What's going on here is that these are the only errno's you can gaurantee
to receive, and make seperate decisions upon.  All other errno's you will
either treat as "ignore" or "hard-fail", that's the typical coding pattern.