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

Michel Dänzer michel at daenzer.net
Thu Jun 22 01:42:21 UTC 2017


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.


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


More information about the dri-devel mailing list