[Intel-gfx] [PATCH] drm: Differentiate the lack of an interface from invalid parameter

[Chris Wilson]

Quoting Daniel Vetter (2018-09-12 10:02:47)
> On Wed, Sep 12, 2018 at 10:50 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > Quoting Daniel Vetter (2018-09-12 09:39:30)
> >> On Wed, Sep 12, 2018 at 10:27 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >> > If the ioctl is not supported on a particular piece of HW/driver
> >> > combination, report ENODEV so that it can be easily distinguished from
> >> > both the lack of the ioctl and from a regular invalid parameter.
> >> >
> >> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >> > Cc: Daniel Vetter <daniel at ffwll.ch>
> >> > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >>
> >> Hm, I thought the canonical errno for "ioctl doesn't apply to this
> >> device" is ENOTTY?
> >
> > That's ioctl doesn't exist. Sometimes it's nice to know the kernel knows
> > about the ioctl but it isn't applicable. Either is fine for my purpose,
> > which is to know the ioctl exists, I just need to distinguish it from
> > EINVAL.
> >
> >> And ENODEV means that it applies, but atm nothing
> >> plugged in, or device gone already.
> >>
> >> I found a few more modeset ioctl:
> >> - drm_mode_gamma_set_ioctl, drm_mode_gamma_get_ioctl
> >> - drm_mode_getconnector
> >> - drm_mode_getcrtc, drm_mode_setcrtc
> >> - drm_mode_getencoder
> >> - drm_mode_create_lease_ioctl, drm_mode_list_lessees_ioctl, ...
> >>
> >> Ok now I stop looking through the grep thing, looks like we've been
> >> using EINVAL consistently. I'm all for switching, it makes sense, but
> >> I think we should at least try to be consistent across all kms ioctl.
> >
> > Ah, but we've been consistent on the other side and have been using
> > ENODEV for the better part of a decade for this meaning (that the ioctl
> > doesn't apply to this HW) :)
> 
> Hm indeed, we've been using either ENODEV or EINVAL for "this ioctl
> doesn't exist/doesn't apply". ENODEV is clearly used in many places
> (also outside of drm) for "hw absent/gone/disappeared". And we have
> very few uses of ENOTTY. So I'm kinda leaning towards starting a new
> trend here, and using ENOTTY for "this ioctl doesn't apply". I don't
> think we need to differentiate this from the case of "this kernel has
> no idea about this ioctl at all", since from a userspace pov there's
> no difference really: Either way it can't use it.
> 
> But I'm also fine if we're just sticking to ENODEV, just feels like
> wasting a perfectly useful errno (and there's not many) if we don't
> give ENOTTY some more use.

In going through the drm_core_checks, I noticed one brave soul used
-ENOTSUPP. How about that?
-Chris