| Please contact Mathieu Desnoyers <mathieu.desnoyers@efficios.com> for |
| questions about this TODO list. The "Cleanup/Testing" section would be |
| good to go through before integration into mainline. The "Features" |
| section is a wish list of features to complete before releasing the |
| "LTTng 2.0" final version, but are not required to have LTTng working. |
| These features are mostly performance enhancements and instrumentation |
| enhancements. |
| |
| TODO: |
| |
| A) Cleanup/Testing |
| |
| 1) Remove debugfs "lttng" file (keep only procfs "lttng" file). |
| The rationale for this is that this file is needed for |
| user-level tracing support (LTTng-UST 2.0) intended to be |
| used on production system, and therefore should be present as |
| part of a "usually mounted" filesystem rather than a debug |
| filesystem. |
| |
| 2) Cleanup wrappers. The drivers/staging/lttng/wrapper directory |
| contains various wrapper headers that use kallsyms lookups to |
| work around some missing EXPORT_SYMBOL_GPL() in the mainline |
| kernel. Ideally, those few symbols should become exported to |
| modules by the kernel. |
| |
| 3) Test lib ring buffer snapshot feature. |
| When working on the lttngtop project, Julien Desfossez |
| reported that he needed to push the consumer position |
| forward explicitely with lib_ring_buffer_put_next_subbuf. |
| This means that although the usual case of pairs of |
| lib_ring_buffer_get_next_subbuf/lib_ring_buffer_put_next_subbuf |
| work fine, there is probably a problem that needs to be |
| investigated in |
| lib_ring_buffer_get_subbuf/lib_ring_buffer_put_subbuf, which |
| depend on the producer to push the reader position. |
| Contact: Julien Desfossez <julien.desfossez@polymtl.ca> |
| |
| |
| B) Features |
| |
| 1) Integration of the LTTng 0.x trace clocks into |
| LTTng 2.0. |
| Currently using mainline kernel monotonic clock. NMIs can |
| therefore not be traced, and this causes a significant |
| performance degradation compared to the LTTng 0.x trace |
| clocks. Imply the creation of drivers/staging/lttng/arch to |
| contain the arch-specific clock support files. |
| * Dependency: addition of clock descriptions to CTF. |
| See: http://git.lttng.org/?p=linux-2.6-lttng.git;a=summary |
| for the LTTng 0.x git tree. |
| |
| 2) Port OMAP3 LTTng trace clocks to x86 to support systems |
| without constant TSC. |
| * Dependency: (B.1) |
| See: http://git.lttng.org/?p=linux-2.6-lttng.git;a=summary |
| for the LTTng 0.x git tree. |
| |
| 3) Implement mmap operation on an anonymous file created by a |
| LTTNG_KERNEL_CLOCK ioctl to export data to export |
| synchronized kernel and user-level LTTng trace clocks: |
| with: |
| - shared per-cpu data, |
| - read seqlock. |
| The content exported by this shared memory area will be |
| arch-specific. |
| * Dependency: (B.1) && (B.2) |
| See: http://git.lttng.org/?p=linux-2.6-lttng.git;a=summary |
| for the LTTng 0.x git tree, which has vDSO support for |
| LTTng trace clock on the x86 architecture. |
| |
| 3) Integrate the "statedump" module from LTTng 0.x into LTTng |
| 2.0. |
| * Dependency: addition of "dynamic enumerations" type to CTF. |
| See: http://git.lttng.org/?p=lttng-modules.git;a=shortlog;h=refs/heads/v0.19-stable |
| ltt-statedump.c |
| |
| 4) Generate system call TRACE_EVENT headers for all |
| architectures (currently done: x86 32/64). |
| |
| 5) Define "unknown" system calls into instrumentation/syscalls |
| override files / or do SYSCALL_DEFINE improvements to |
| mainline kernel to allow automatic generation of these |
| missing system call descriptions. |
| |
| 6) Create missing tracepoint event headers files into |
| instrumentation/events from headers located in |
| include/trace/events/. Choice: either do as currently done, |
| and copy those headers locally into the lttng driver and |
| perform the modifications locally, or push TRACE_EVENT API |
| modification into mainline headers, which would require |
| collaboration from Ftrace/Perf maintainers. |
| |
| 7) Poll: implement a poll and/or epoll exclusive wakeup scheme, |
| which contradicts POSIX, but protect multiple consumer |
| threads from thundering herd effect. |
| |
| 8) Re-integrate sample modules from libringbuffer into |
| lttng driver. Those modules can be used as example of how to |
| use libringbuffer in other contexts than LTTng, and are |
| useful to perform benchmarks of the ringbuffer library. |
| See: http://www.efficios.com/ringbuffer |
| |
| 9) NOHZ support for lib ring buffer. NOHZ infrastructure in the |
| Linux kernel does not support notifiers chains, which does |
| not let LTTng play nicely with low power consumption setups |
| for flight recorder (overwrite mode) live traces. One way to |
| allow integration between NOHZ and LTTng would be to add |
| support for such notifiers into NOHZ kernel infrastructure. |
| |
| 10) Turn drivers/staging/lttng/ltt-probes.c probe_list into a |
| hash table. Turns O(n^2) trace systems registration (cost |
| for n systems) into O(n). (O(1) per system) |
| |
| 11) drivers/staging/lttng/probes/lttng-ftrace.c: |
| LTTng currently uses kretprobes for per-function tracing, |
| not the function tracer. So lttng-ftrace.c should be used |
| for "all" function tracing. |
| |
| 12) drivers/staging/lttng/probes/lttng-types.c: |
| This is a currently unused placeholder to export entire C |
| type declarations into the trace metadata, e.g. for support |
| of describing the layout of structures/enumeration mapping |
| along with syscall entry events. The design of this support |
| will likely change though, and become integrated with the |
| TRACE_EVENT support within lttng, by adding new macros, and |
| support for generation of metadata from these macros, to |
| allow description of those compound types/enumerations. |
| |
| Please send patches |
| To: Greg Kroah-Hartman <greg@kroah.com> |
| To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> |