Thanks for valuable comments. I have no objection to your advice that overlapping the similar implementation should be avoided. Let me make change the current implementation into the extension of the existing codes, and if there are any problems in extending, please let me discuss again.
Regarding to another issue, the place of the application side code, it is because I have wanted to implement trace cmd "<command>" It gets the trace while executing the specified command line like "time" command of nsh. It requires nsh_parse() nshlib internal API. Thanks, Yuuichi Nakamura > -----Original Message----- > From: Gregory Nutt <spudan...@gmail.com> > Sent: Wednesday, June 17, 2020 11:13 AM > To: dev@nuttx.apache.org > Subject: Re: NXView > > > > The major differences are: > > > > - Different trace data format between the accumulated data in the memory and > /dev/tracer output > > It is because to reduce the trace data size in the memory. The > > accumulated > data contains packed (not aligned) values and > > task is recorded by its PID, not the name. The correspondence between PID > and task name string is hold in the separated task name buffer. > > On the other hand, the output from /dev/tracer contains aligned words and > contains the task name string for each trace entries. > > It is because easy to handle the data by the application code (nsh trace > command). > > That is a trivial difference and there are some misconceptions. > > The structures can be packed by simply adding the packed attribute to the > structures. That does not justify a redesign. > > The current implementation does *not* use the task name, it uses the pid. The > task name is provided only when the task is created. The provides the > associated between pid and name. Thereafter only the pid is uses. > > Your implementation has two much overlap and should not come upstream as a > separate implementation. Extensions and improvements to the existing > implementation are welcome, however. > > Greg
