Some comments:
1. I don't think that there should be two implementations that are so
similar. There should be only one. But I am open to extending/merging
that one, common implementation.
2. nsh is not an appropriate place for the application side code. That
should go in apps/system. Perhaps not in apps/system/sched_note;
perhaps a unique application for your purpose. It is not an appropriate
command to reside within the shell, however.
Greg
On 6/16/2020 8:03 PM, Nakamura, Yuuichi (Sony) wrote:
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
