> I did that. I created PR 1256 with the commit in your name Thank you!
I want to mainline the feature by issuing the additional PRs for the remaining part. As you pointed out, the codes are based on the existing sched note logic. The reason of preparing another files is the changes for this feature affects the existing logic. Of course, the code duplication should be avoided. So if needed I want to change it to modification of the existing codes. Please let me keep discussion in ML or new PR to make the code acceptable into the maineline. > Are there other functional differences? Should these related implementations > be merged in some way? 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). - Additional ioctl functions in /dev/tracer driver There are many features which can be controlled by the application such as system call trace filters. So the driver has ioctl handlers for it. Of course, sched_tracer.c has the code to handle the filters. I feel that the code should be separate into the different PRs: - remaining system call trace support code which requires the modification to the build system - sched tracer and device driver which uses new sched note APIs (needs more discussion) Thanks, Yuuichi Nakamura > -----Original Message----- > From: Gregory Nutt <spudan...@gmail.com> > Sent: Tuesday, June 16, 2020 11:11 PM > To: dev@nuttx.apache.org > Subject: Re: NXView > > eg > > > > Regardless of that decision, it would be nice if you could at least > > upstream the interrupt and system call instrumentation. That will be > > needed in any event and we should re-use that logic, not re-invent it. > > > I did that. I created PR 1256 with the commit in your name
