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

[Daniel Vetter]

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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch