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

[Christian König]

Am 12.09.2018 um 11:12 schrieb 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?

+1 for that as well and I'm pretty sure I have seen that in a couple of 
drivers if an IOCTL isn't supported for a specific device.

Christian.

> -Chris
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel