<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">- This one is a big change in my patch (at least to me, it is). I tried<br>what esyr suggested, providing fallback definitions of DRM_IOCTL related<br>structures and all those constants in strace/linux/linux/drm.h. There is<br>a drm_mode.h, too. I'm not sure if this is compliant with strace's<br>tradition (probably not) so I hope I can get feedbacks :).<br>For now, the changes are in [1]. I simply bundle the latest kernel headers<br>(ioc32 compat definitions are included) up in strace to see if it works.<br><br>[1] <a href="https://github.com/haoyouab/strace/commit/6db1c500cebfc8ec2e600f5f6ea182cd3e237f82" target="_blank">https://github.com/haoyouab/strace/commit/6db1c500cebfc8ec2e600f5f6ea182cd3e237f82</a><br><br></div></blockquote><div>I met a weird condition here. Some mx32 tests failed on travis-ci and part<br>of the logs are listed below:<br><br>-ioctl(-1, DRM_IOCTL_VERSION, NULL) = -1 EBADF (Bad file descriptor)<br>+ioctl(-1, _IOC(_IOC_READ|_IOC_WRITE, 0x64, 0, 0x40), 0) = -1 EBADF (Bad file descriptor)<br><br>Obviously it's ouput mismatch but the thing I don't understand is why only<br>mx32, not m32? In m32 and mx32 the size of the corresponding structure are<br>both 0x24 bytes. I found that mpers-m32/struct_drm_vesion.h is generated<br>with the right compat size but structure in mpers-mx32/struct_drm_version.h<br>is 0x40 bytes, which is not a compat one. I wonder how this is generated?<br><br>The other thing weird is that on my local machine, structure for mx32 is<br>0x24, which is different from the one on travis-ci. Is that because I use a<br>newer distribution or kernel?<br></div></div></div>