patacongo commented on a change in pull request #1271:
URL: https://github.com/apache/incubator-nuttx/pull/1271#discussion_r443120016
##########
File path: sched/Kconfig
##########
@@ -975,7 +975,7 @@ config SCHED_INSTRUMENTATION_SPINLOCKS
config SCHED_INSTRUMENTATION_SYSCALL
bool "System call monitor hooks"
default n
- depends on LIB_SYSCALL && ARCH_HAVE_SYSCALL_HOOKS
+ depends on ARCH_HAVE_SYSCALL_HOOKS
Review comment:
I think that there there still must be an option to enable the
instrumentation in the syscall stubs. We have to be able to generate stubs
without the instrumentation. But yes, if it is inside of the syscall stubs,
then that part of the logic does not need to be conditioned on
CONFIG_LIB_SYSCALL.
But how about the generation of the event handling logic itself?
Some of this comes back to enabling static vs. runtime instrumentation. The
static controls are essential for resource limited and for systems with
extremely high data rate events.
Better terminology... we need "frontend" and possibly "backend" controls:
There are basically two steps:
frontend: instrumentation calls are received and data is buffered in memory.
backend: The application reads the data from memory.
We need frontend controls to manage how much data is buffered and the rate
of buffering. That was accomplished in the past through static configuration
settings. If you want to avoid static settings, then you will need other
controls to manage the rate that data is buffered.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
