From: Mathieu Desnoyers Date: Fri, 9 Dec 2011 14:15:49 +0000 (-0500) Subject: Add TODO file X-Git-Tag: v2.0-pre11~8 X-Git-Url: https://git.lttng.org./?a=commitdiff_plain;h=720c9a064aba98f4ac65f1081c12f79e87917441;p=lttng-modules.git Add TODO file Signed-off-by: Mathieu Desnoyers --- diff --git a/TODO b/TODO new file mode 100644 index 00000000..d0d380aa --- /dev/null +++ b/TODO @@ -0,0 +1,124 @@ +Please contact Mathieu Desnoyers 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) 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 + + +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: Mathieu Desnoyers