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@xxxxxxxxxxxxxxxxxx> wrote:
Quoting Daniel Vetter (2018-09-12 09:39:30)
On Wed, Sep 12, 2018 at 10:27 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
Cc: Daniel Vetter <daniel@xxxxxxxx>
Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
