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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
