Messages in this thread | | | Date | Wed, 27 May 2009 09:59:12 +0800 | From | Li Zefan <> | Subject | Re: [PATCH v2 1/2] tracing/events: make __string() more general |
| |
Steven Rostedt wrote: > On Wed, 27 May 2009, Li Zefan wrote: > >> Steven Rostedt wrote: >>> On Tue, 26 May 2009, Li Zefan wrote: >>> >>>> This changes __string(..., src) to __string(..., len), thus makes it more >>>> general, and then block TRACE_EVENT() can use it. >>>> >>>> Also introduce __fetch_str(), which is used in TP_assign() and returns >>>> the address of the string, while __get_str() is used in TP_print(). >>>> >>>> [ Impact: TRACE_EVENT api change ] >>> What's the reason for the change? >>> >>> Is it to handle NULL pointers? If so, lets change the ftrace.h to handle >>> it instead. >>> >> No, not for this purpose. >> >> With __string(..., src), we need to have a source string, but sometimes no >> source string is available, and what we know is how big the string will be. >> >> Take block trace events for example, I want to convert an unsigned char array >> into a string, after this patch, this can be done this way: >> >> TP_STRUCT_entry( >> __string( cmd, rq->cmd_len * 3 ) >> ) >> >> TP_fast_assign( >> construct_str( cmd ) > > What does the construct_str do? >
Ah, it's pseudo code.. Should be construct_str(__entry->cmd, rq), this helper function convert rq->cmd (unsigned char[]) to a string of hex dump.
No source string is available, so I'm not calling assign_str() in TP_fast_assign.
> >> ) >> >> TP_prink("%s\n", get_str(cmd)) >> >> Seems Christoph also runs into this problem while doing his XFS tracing. >> (and NULL str ptr that I'm not suffering) >> >>> This is why I like the Impact line really be a "rational" line. >>> "TRACE_EVENT api change" is meaningless to me. >>> >> So what should this impact be. :( > > That's the point. I don't know the purpose of the patch except that it > changes the API. But changing the API is the means to the end. I'm still > confused by what the end is. >
| |