Re: [PATCH v3] dma: Trace API

[Sean Anderson <sean.anderson@linux.dev>]

On 9/3/24 09:21, Steven Rostedt wrote:
> On Tue, 3 Sep 2024 09:25:12 +0200
> Christoph Hellwig <hch@lst.de> wrote:
> 
>> On Thu, Aug 29, 2024 at 10:24:52AM -0400, Sean Anderson wrote:
>> > >> When debugging drivers, it can often be useful to trace when memory gets
>> > >> (un)mapped for DMA (and can be accessed by the device). Add some
>> > >> tracepoints for this purpose.
>> > >> 
>> > >> We use unsigned long long instead of phys_addr_t and dma_addr_t (and
>> > >> similarly %llx instead of %pa) because libtraceevent can't handle
> 
> I think the issue is that libtraceevent doesn't handle "%pa", which I can
> fix.

With s/unsigned long long/u64/g I get

kworker/2:1H-mm     183 [002]    32.472411:                 dma:dma_unmap_sg: [FAILED TO PARSE] device=ff160000.mmc addrs=ARRAY[00, 50, e2, 06, 08, 00, 00, 00] dir=2 attrs=0x0

>> > >> typedefs.  
>> > > 
>> > > and a __u64 would seem like the better type here.  
>> > 
>> > libtraceevent can't handle typedefs, including u64.  
>> 
>> Weird.  The xfs trace events which were some of the first ever are full
>> of typedefs and no one ever complained.  And looking at other
>> trace event definitions they are full of it.
>> 
>> I've added the tracing maintainers to see if we can shed some light
>> on this issue.
> 
> libtraceevent doesn't even really bother with the types. It gets its
> information from the other fields.
> 
> For example:
> 
>  events/x86_fpu/x86_fpu_after_restore/format:	field:u64 xfeatures;	offset:24;	size:8;	signed:0;
> 
> 
> The "field:u64" is more for humans than the tools. And it can be used for
> hints when the printfmt fails to parse. But the libtraceevent really looks
> at the "offset", "size" and "signed" to know how to use that number.

This doesn't apply for arrays:

	field:__data_loc u64[] addrs;	offset:12;	size:4;	signed:0;

Here the size is not for the data type but for the array. And so the
type is parsed by process_sizeof in src/event-parse.c.

--Sean