[Intel-gfx] [PATCH] drm/i915: Return -EPERM when i915_gem_mmap_ioctl handling prime objects

[Joonas Lahtinen]

On Fri, 2017-08-18 at 10:03 +0200, Daniel Vetter wrote:
> On Wed, Aug 16, 2017 at 03:26:43AM +0000, Zhang, Tina wrote:

<SNIP>

> > > Quoting Daniel Vetter (2017-08-15 15:48:03)
> > > > On Tue, Aug 15, 2017 at 4:35 PM, Chris Wilson <chris at chris-wilson.co.uk>

<SNIP>

> > > > - If we need that special errno, can we take something else? EPERM imo
> > > > has fairly specific meaning. ENODEV/ENOTTY are more the "not supported
> > > > on this thing" error codes, if we need a special one. They also have
> > > > other meanings attached already, but then everything excpe EINVAL has
> > > > when we do an ioctl, since the vfs can already throw these at you
> > > > anyway.
> > > 
> > > ENODEV at the ioctl level we already have to mean that the device doesn't
> > > support the operation, but not the object. (Then internally we've used ENODEV
> > > to indicate programmer error.)
> > > 
> > > ENOTTY too easy to confuse with the absent ioctl?
> > > 
> > > ENXIO is not bad, basically says the remote channel does not support the
> > > operation.
> > 
> > "ENXIO" looks fine to me. If everyone is onboard with this, we will replace "EINVAL" with it
> > in this patch, and also the ones in https://patchwork.freedesktop.org/patch/168810/
> > Thanks.
> 
> +1 on ENXIO. I reviewed usage in drm, and mostly it's used for probe time
> cases where the other endpoint wasn't found/didn't reply. It's a bit a
> stretch, but seems to fit best at least.

Daniel, I think you've just signed up for writing a nice section of
kerneldoc about this ;) Include the reasoning too, then it'll be easier
to be consistent in the future.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation