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? -Chris _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
