Zhibin Li's GSoC status report - #10 of 12

[Zhibin Li]

>
> - This one is a big change in my patch (at least to me, it is). I tried
> what esyr suggested, providing fallback definitions of DRM_IOCTL related
> structures and all those constants in strace/linux/linux/drm.h. There is
> a drm_mode.h, too. I'm not sure if this is compliant with strace's
> tradition (probably not) so I hope I can get feedbacks :).
> For now, the changes are in [1]. I simply bundle the latest kernel headers
> (ioc32 compat definitions are included) up in strace to see if it works.
>
> [1]
> https://github.com/haoyouab/strace/commit/6db1c500cebfc8ec2e600f5f6ea182cd3e237f82
>
> I met a weird condition here. Some mx32 tests failed on travis-ci and part
of the logs are listed below:

-ioctl(-1, DRM_IOCTL_VERSION, NULL) = -1 EBADF (Bad file descriptor)
+ioctl(-1, _IOC(_IOC_READ|_IOC_WRITE, 0x64, 0, 0x40), 0) = -1 EBADF (Bad
file descriptor)

Obviously it's ouput mismatch but the thing I don't understand is why only
mx32, not m32? In m32 and mx32 the size of the corresponding structure are
both 0x24 bytes. I found that mpers-m32/struct_drm_vesion.h is generated
with the right compat size but structure in mpers-mx32/struct_drm_version.h
is 0x40 bytes, which is not a compat one. I wonder how this is generated?

The other thing weird is that on my local machine, structure for mx32 is
0x24, which is different from the one on travis-ci. Is that because I use a
newer distribution or kernel?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20190806/2c4a6024/attachment.html>