Thanks, Brennan and Petr, for the recommendations.
At this point, I am only trying to ascertain if there are a few people
interested in participating in such a project. I think it is more that
I can consider to do alone so any further steps would require some
interest in the development itself.
Brennan, you asked about the target side effort. That would be pretty
small because the instrumentation was build into the OS on day one. You
can see this in sched/Kconfigs for the description of
CONFIG_SCHED_INSTRUMENTATION. When that the option is enabled, OS hooks
in the form of call-outs are enabled.
There is some current use of those call-outs now for target-side,
software monitoring of the scheduler.
- There is logic sched/sched/sched_note.c that will buffer the
instrumented data in memory
- There is a character driver at drivers/syslog/note_driver.c that will
export the buffered instrumentation to any application via a character
driver
- There is an application at apps/system/sched_note that will use that
driver to periodically show OS activity
None of this, of course would be used in the proposed host-based
monitoring except for the raw OS call-outs. For this proposal, a modest
amount of new development would be needed:
- Board-specific initialization of the parallel interface (like the
FMC/FSMC in STM32 MCUs) so that writes to a memory mapped address will
add data to the FIFO.
- A new module that would (1) receive the OS instrumentation call-outs,
(2) encode/marshal the scheduler event data into a byte stream, and (3)
transfer the data to the FIFO by writing the byte stream to the memory
mapped address
That is not such a big effort. The other efforts would be to
configuration the host-side USB driver, verify proper transfer of data,
and develop the application to present the data graphically. Those, I
believe, are more effort than the work on the target side.
So, in general, I think the target side is in good shape for this use.
Greg
