On Tue, Aug 15, 2017 at 3:18 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > Quoting Daniel Vetter (2017-08-15 11:49:51) >> On Tue, Aug 15, 2017 at 10:42 AM, Tina Zhang <tina.zhang@xxxxxxxxx> wrote: >> > Prime objects have no backing filp to GEM mmap pages from. So, for Prime >> > objects, such operation is not permitted. >> >> EPERM is when you don't have enough permissions, but it's possible >> (e.g. a feature requiring root, or drm master). -EINVAL is if >> something is invalid, and not even root can change that. So from a >> consistency pov, EINVAL is the right error code here I think. > > Consistency is that we wanted the same error code for all objects where > you did not have the ability to change the underlying storage. > > The question is that an access issue or a permission issue. But at the > very least, mmap_ioctl is the odd one out. Which the changelog did not > explain and being sent out of context does not help. Which other ioctl give you an EPERM for something that doesn't even work when you're root and/or drm master or whatever it is that gives you permission? I thought we've been pretty consistent with that one ... -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
