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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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) :)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux