[Sound-open-firmware] [PATCH] [RFC]rmbox: include trace class definitions from trace header

[Yan Wang]

On 5/18/2018 2:38 AM, Liam Girdwood wrote:
> On Thu, 2018-05-17 at 10:48 -0700, Ranjani Sridharan wrote:
>>>
>>>
>>> What's this for ? You can use AC_ macro in configure.ac to detect the
>>> presence
>>> of an installed header.
>>
>> because the SOF headers wont be installed on the device that we run
>> rmbox on, I've bundled up the header in the executable.
>> And the above definitions are to rename the symbols in the executable
>> to something like trace_start and trace_end to access the trace class
>> definitions from the header.
>>
>> I couldnt think of a way better way that including the trace header
>> object in the rmbox application.  Is this acceptable?
> 
> So the trace class strings are deprecated, Yan was going to export all the trace
> object names + IDs via debugfs (like DAPM widgets already do). rmbox should read
> these at startup so it could then lookup comp name from the ID number embedded
> in trace data.
> 
> Yan, do you have parts of this implemented ?

In my previous RFC v2 patch set, I still keep trace class macro 
definition in trace record but support switch on/off based component id.
I am working on displaying compoent/widget name in rmbox and will submit 
in the next version patch set.
But for global trace like DMA/IPC/... or early component trace which 
locates in comp_new()/pipe_new()/buffer_new() may still need trace class 
because they haven't corresponding component/widget name?

Thanks.
Yan Wang

> 
> Liam
>