[Intel-gfx] [PATCH] drm/i915: Consistent ordering of tracepoint binary data

[Tvrtko Ursulin]

On 11/05/2017 14:16, Tvrtko Ursulin wrote:
> 
> On 11/05/2017 14:07, Chris Wilson wrote:
>> On Thu, May 11, 2017 at 02:00:45PM +0100, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>>>
>>> For userspace receiving binary data it is easier if all related
>>> request tracepoints emit the binary data in the same order of
>>> dev, ring, ctx, seqno, ...
>>
>> We decided that dev, ctx, ring, seqno was the right heirachy last time.
>> After much debate :)
>> ctx is the logical view of the device for a user
>> ctx + ring = timeline
> 
> I couldn't remember so I thought it must have been what is documented in 
> TP_printk. Now I am confused. On one hand it's true, but on the other 
> ctx/seqno is also a pair as opposed to engine being stuck in the middle. 
> So ring-ctx-seqno is easier for humans I think. Even since per 
> ctx/engine seqno space.

[thread bump!]

Can we agree what to do here? Printk's are all engine-ctx-seqno which 
makes it sound like that was the order we agreed upon. But binary blobs 
are inconsistent as you have noticed - do we care enough to go and 
fiddle with that is the question? Is overlay the only userspace to your 
knowledge that accesses the binary blobs?

Regards,

Tvrtko