On Fri, 2017-08-18 at 10:03 +0200, Daniel Vetter wrote: > On Wed, Aug 16, 2017 at 03:26:43AM +0000, Zhang, Tina wrote: <SNIP> > > > Quoting Daniel Vetter (2017-08-15 15:48:03) > > > > On Tue, Aug 15, 2017 at 4:35 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> <SNIP> > > > > - If we need that special errno, can we take something else? EPERM imo > > > > has fairly specific meaning. ENODEV/ENOTTY are more the "not supported > > > > on this thing" error codes, if we need a special one. They also have > > > > other meanings attached already, but then everything excpe EINVAL has > > > > when we do an ioctl, since the vfs can already throw these at you > > > > anyway. > > > > > > ENODEV at the ioctl level we already have to mean that the device doesn't > > > support the operation, but not the object. (Then internally we've used ENODEV > > > to indicate programmer error.) > > > > > > ENOTTY too easy to confuse with the absent ioctl? > > > > > > ENXIO is not bad, basically says the remote channel does not support the > > > operation. > > > > "ENXIO" looks fine to me. If everyone is onboard with this, we will replace "EINVAL" with it > > in this patch, and also the ones in https://patchwork.freedesktop.org/patch/168810/ > > Thanks. > > +1 on ENXIO. I reviewed usage in drm, and mostly it's used for probe time > cases where the other endpoint wasn't found/didn't reply. It's a bit a > stretch, but seems to fit best at least. Daniel, I think you've just signed up for writing a nice section of kerneldoc about this ;) Include the reasoning too, then it'll be easier to be consistent in the future. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
