[PATCH libdrm 1/2] xf86drm: inline drmIoctl()

Eric Engestrom eric.engestrom at imgtec.com
Thu Jun 22 14:45:49 UTC 2017


On Thursday, 2017-06-22 10:42:21 +0900, Michel Dänzer wrote:
> On 22/06/17 08:16 AM, Eric Engestrom wrote:
> > As Chad [1] puts it:
> >> it's excessive to jump through the PLT into a shared object for a mere
> >> ioctl wrapper.
> > 
> > [1] https://lists.freedesktop.org/archives/mesa-dev/2017-June/159951.html
> > 
> > Signed-off-by: Eric Engestrom <eric at engestrom.ch>
> 
> NAK, at least in this form:
> 
> 
> > diff --git a/xf86drm.c b/xf86drm.c
> > index 728ac78c..c82a76d2 100644
> > --- a/xf86drm.c
> > +++ b/xf86drm.c
> > @@ -179,20 +179,6 @@ void drmFree(void *pt)
> >      free(pt);
> >  }
> >  
> > -/**
> > - * Call ioctl, restarting if it is interupted
> > - */
> > -int
> > -drmIoctl(int fd, unsigned long request, void *arg)
> > -{
> > -    int ret;
> > -
> > -    do {
> > -        ret = ioctl(fd, request, arg);
> > -    } while (ret == -1 && (errno == EINTR || errno == EAGAIN));
> > -    return ret;
> > -}
> 
> libdrm.so.2 must continue exporting a working drmIoctl symbol, otherwise
> it's an ABI break.

Oops, you're absolutely right, my bad :/

> 
> 
> Also, there are downsides to exposing library API calls as inline
> functions: E.g. if drmIoctl(2) ever needs a change (worst case a
> security bug fix), every user has to be recompiled to get the fix. It's
> kind of like static linking through the back door. Is it really worth it
> for drmIoctl(2)? Are they ever an actual bottleneck?

The start of the conversation [1] was that the profiler was spending
more time going through drmIoctl() than the actual syscall, which
prompted Chris to write a local copy that would be inlined, and the fact
some of that time was spend converting the error returned into a `-1`
and set the error in `errno`, which is rather pointless from a caller's
perspective.

I simply took his proposal and applied it to libdrm, although I obviously
did so badly.

Is the updatability of a loop around ioctl() really an issue?
I can drop the first patch and respin the second as a normal dso function,
would that be something people are interested in?

[1] https://lists.freedesktop.org/archives/mesa-dev/2017-June/159894.html

> 
> 
> -- 
> Earthling Michel Dänzer               |               http://www.amd.com
> Libre software enthusiast             |             Mesa and X developer


More information about the dri-devel mailing list