Will remove the duplicated check (it's already checked within
lib_ring_buffer_mmap_buf), and push to gregkh in my next round, thanks!
Mathieu
* Dan Carpenter (dan.carpen...@oracle.com) wrote:
Hello Mathieu Desnoyers,
This is a semi-automatic email about new static checker warnings.
The
On 11-11-30 07:42 AM, fahimeh soltaninejad wrote:
hi, when i was installing the binary package of lttng, when i wrote
sudo apt-get install lttng in command line i found a error which was:
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to
* Dan Carpenter dan.carpen...@oracle.com wrote:
[...]
The patch c844b2f5cfea: lttng lib: ring buffer from Nov 28, 2011,
leads to the following Smatch complaint:
drivers/staging/lttng/lib/ringbuffer/ring_buffer_frontend.c +1150
+lib_ring_buffer_print_buffer_errors()
warn: variable
Use the newly exported vmalloc_sync_all symbol.
Signed-off-by: Mathieu Desnoyers mathieu.desnoy...@efficios.com
---
.../lttng/lib/ringbuffer/ring_buffer_backend.c |3 +-
drivers/staging/lttng/ltt-context.c|1 -
drivers/staging/lttng/ltt-debugfs-abi.c|3
LTTng needs this symbol to prepend the current task dynamic priority
value to events (optional context information).
Exporting to all modules following the similar task_nice().
Signed-off-by: Mathieu Desnoyers mathieu.desnoy...@efficios.com
---
kernel/sched.c |1 +
1 files changed, 1
LTTng was using a non-exported ftrace symbol,
register_ftrace_function_probe(), for function-by-function selection for
function tracing.
We prefer to use kretprobes to do this, which gives us function entry
and exit.
Ftrace function tracer approach makes sense when selecting _all_
functions for
Use the newly exported task_prio symbol.
Signed-off-by: Mathieu Desnoyers mathieu.desnoy...@efficios.com
---
drivers/staging/lttng/lttng-context-prio.c | 23 +--
1 files changed, 1 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/lttng/lttng-context-prio.c
I thinkg it might be useful if I could get some representation
(graphical or otherwise) about the number of RUNNable tasks at any
given time to get an idea of how much contention is ongoing on the CPU.
So I guess something like the following information:
- peak measurement of the running
The two eval's are needed to correctly expand the variables in the
default path. Anyone know of a cleaner way to achieve this?
RFC to also discuss the following:
- Should we also print the information about the $bindir and $libdir
this current build with install into?
- Right now to
