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

[Zhibin Li]

Hi all,

I just finished my final so I didn't do much last week.

Accomplishments:
- Went through i915 source code to mark down what's missing in the original
patch set.
- Started to test i915 manually. But I came across some problems (I will
mention them below in the questions section.

Questions:
When I started to test i915 ioctls, I found that it can't be integrated
into strace's test suite. Please take a look at [1]. It makes sense that
Patrik uses the driver name linked to the file descriptor to identify the
specific device. After that the matched ioctl decoder will be invoked.
Here's my question: Is there any way to tamper the path linked to the fd?
Something like injection? I mean we usually use fd = -1 in the test but in
this case it won't work because a valid driver name has to be obtained from
the fd. Using -1 will simply match no devices.
Or can we tamper the priv_data in struct tcb when we run tests? Because the
driver name is stored in priv_data.
I'm able to test those device specific ioctls by simply returning them. For
example there is if...else clause to determine which (i915 or something
else) decoder to invoke. When I want to test i915, I can temporarily remove
the if...else and return i915_drm_ioctl(). In this way I can manually test
if it works.

TODO:
- As mentioned above, I'm still looking for a better way to test them.
- Add missing functions in i915 decoder.

BTW is the IRC logger robot absent? I can't see any logs from [2] anymore.

[1] https://github.com/haoyouab/strace/blob/stuff/drm.c#L28
[2] https://strace.io/logs

Thanks,
Zhibin Li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20190610/124e0429/attachment.html>