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@xxxxxxxxxxxx> 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. 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? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
