[Mesa-dev] [PATCH 1/2] RFC i965: Bypass a couple of libraries for syscall on x84_64

[Eric Engestrom]

On Monday, 2017-06-19 12:22:07 -0700, Chad Versace wrote:
> The other reason for removing all uses of drmIoctl() is, imo, it's
> excessive to jump through the PLT into a shared object for a mere ioctl
> wrapper.

Agreed, but doesn't my suggestion of moving drmIoctl() to the drm header
as either a static inline function or a macro already avoid all that?

> > 
> > So to be clear, there are two issues:
> > - profiler showing more time spent in userspace handling of the ioctl
> >   than the actual kernel call
> > - return value handling mismatch
> > 
> > For the time issue, how about we move drmIoctl() directly in xf86drm.h
> > and make it `static inline` like your functions, or even a macro?
> > 
> > For the return value issue, how about introducing a drmIoctl2() (with
> > a better name :P) with your assembly code and the -errno return value,
> > and maybe even the `EINTR || EAGAIN` loop integrated?
> > 
> > drmIoctl2() would of course have the improvements from drmIoctl() :)
> > 
> > This should give you all the improvements of your patches here, while
> > still using the standard libdrm functions.
> 
> We should have less libdrm, not more, in the Intel drivers. I don't
> object to anyone adding drmIoctl2() to libdrm headers, but the Intel
> drivers shouldn't use it. i965 should be doing the same thing as anv
> regarding ioctls: implement the ioctl wrapper in-tree.
> 
> Chris, if you rewrote this patch with the controversial part omitted
> [that is, without re-implementing libc's ioctl()], then I would give
> a r-b. That patch would be a definite improvement over the status quo.
> Then we could debate the merits of "libc's ioctl() vs raw syscall"
> after that patch landed.

Not nacking or anything, so sure, go ahead, this can always be changed
later if we come to another agreement.

Cheers,
  Eric