Re: [PATCH 3/8] usb: udc: trace: reduce buffer usage of trace event

[Linyu Yuan <quic_linyyuan@quicinc.com>]

On 9/15/2023 10:16 AM, Steven Rostedt wrote:
> On Fri, 15 Sep 2023 09:11:06 +0800
> Linyu Yuan <quic_linyyuan@quicinc.com> wrote:
>
>>>> +		snprintf(__s, 9, "ep%d%s", te.address, \
>>>> +			(te.caps.dir_in && te.caps.dir_out) ? "" : \
>>>> +			te.caps.dir_in ? "in" : "out");
>>> Note, there's a temp buffer trace_seq 'p' available for use as well. See
>>> both include/trace/events/libata.h and include/trace/events/scsi.h:
>>>
>>>     const char *libata_trace_parse_status(struct trace_seq*, unsigned char);
>>>     #define __parse_status(s) libata_trace_parse_status(p, s)
>>>
>>> I think that can be used instead of adding this TP_printk_init().
>>
>> the reason add TP_printk_init() because when i first design some macro
>> which not
>>
>> related to tracepoint,  it use too much stack.
>>
> Not sure what you mean about 'uses too much stack'. This is called by
> the reading code and not some arbitrary location, and the above macros
> are done in the same location as your "init" call, so I'm not sure how
> that makes a difference on the stack.
>
>> but i think  TP_printk_init()  is good as it following most common way
>> to print.
>>
> I really do not want to add more versions of TRACE_EVENT() that I need
> to maintain unless there is a really good reason to do so.
>
> And I really don't want to encourage the use of a "TP_printk_init()"
> because that just encourages more use cases that will make it hard for
> user space to parse the TP_printk().


that's true, it is difficult to understand, when i add this new, it 
report build issue.


will consider other way for this case without new tracepoint macro.



>
> -- Steve