TODO

   1 Please contact Mathieu Desnoyers <mathieu.desnoyers@efficios.com> for
   2 questions about this TODO list. The "Cleanup/Testing" section would be
   3 good to go through before integration into mainline. The "Features"
   4 section is a wish list of features to complete before releasing the
   5 "LTTng 2.0" final version, but are not required to have LTTng working.
   6 These features are mostly performance enhancements and instrumentation
   7 enhancements.
   8
   9 TODO:
  10
  11 A) Cleanup/Testing
  12
  13         1) Test lib ring buffer snapshot feature.
  14            When working on the lttngtop project, Julien Desfossez
  15            reported that he needed to push the consumer position
  16            forward explicitely with lib_ring_buffer_put_next_subbuf.
  17            This means that although the usual case of pairs of
  18            lib_ring_buffer_get_next_subbuf/lib_ring_buffer_put_next_subbuf
  19            work fine, there is probably a problem that needs to be
  20            investigated in
  21            lib_ring_buffer_get_subbuf/lib_ring_buffer_put_subbuf, which
  22            depend on the producer to push the reader position.
  23            Contact: Julien Desfossez <julien.desfossez@polymtl.ca>
  24
  25
  26 B) Features
  27
  28         1) Integration of the LTTng 0.x trace clocks into
  29            LTTng 2.0.
  30              Currently using mainline kernel monotonic clock. NMIs can
  31              therefore not be traced, and this causes a significant
  32              performance degradation compared to the LTTng 0.x trace
  33              clocks. Imply the creation of drivers/staging/lttng/arch to
  34              contain the arch-specific clock support files.
  35              * Dependency: addition of clock descriptions to CTF.
  36            See: http://git.lttng.org/?p=linux-2.6-lttng.git;a=summary
  37                 for the LTTng 0.x git tree.
  38
  39         2) Port OMAP3 LTTng trace clocks to x86 to support systems
  40            without constant TSC.
  41             * Dependency: (B.1)
  42            See: http://git.lttng.org/?p=linux-2.6-lttng.git;a=summary
  43                 for the LTTng 0.x git tree.
  44
  45         3) Implement mmap operation on an anonymous file created by a
  46            LTTNG_KERNEL_CLOCK ioctl to export data to export
  47            synchronized kernel and user-level LTTng trace clocks:
  48            with:
  49               - shared per-cpu data,
  50               - read seqlock.
  51            The content exported by this shared memory area will be
  52            arch-specific.
  53            * Dependency: (B.1) && (B.2)
  54            See: http://git.lttng.org/?p=linux-2.6-lttng.git;a=summary
  55                 for the LTTng 0.x git tree, which has vDSO support for
  56                 LTTng trace clock on the x86 architecture.
  57
  58         3) Integrate the "statedump" module from LTTng 0.x into LTTng
  59            2.0.
  60              * Dependency: addition of "dynamic enumerations" type to CTF.
  61            See: http://git.lttng.org/?p=lttng-modules.git;a=shortlog;h=refs/heads/v0.19-stable
  62                 ltt-statedump.c
  63
  64         4) Generate system call TRACE_EVENT headers for all
  65            architectures (currently done: x86 32/64).
  66
  67         5) Define "unknown" system calls into instrumentation/syscalls
  68            override files / or do SYSCALL_DEFINE improvements to
  69            mainline kernel to allow automatic generation of these
  70            missing system call descriptions.
  71
  72         6) Create missing tracepoint event headers files into
  73            instrumentation/events from headers located in
  74            include/trace/events/. Choice: either do as currently done,
  75            and copy those headers locally into the lttng driver and
  76            perform the modifications locally, or push TRACE_EVENT API
  77            modification into mainline headers, which would require
  78            collaboration from Ftrace/Perf maintainers.
  79
  80         7) Poll: implement a poll and/or epoll exclusive wakeup scheme,
  81            which contradicts POSIX, but protect multiple consumer
  82            threads from thundering herd effect.
  83
  84         8) Re-integrate sample modules from libringbuffer into
  85            lttng driver. Those modules can be used as example of how to
  86            use libringbuffer in other contexts than LTTng, and are
  87            useful to perform benchmarks of the ringbuffer library.
  88            See: http://www.efficios.com/ringbuffer
  89
  90         9) NOHZ support for lib ring buffer. NOHZ infrastructure in the
  91            Linux kernel does not support notifiers chains, which does
  92            not let LTTng play nicely with low power consumption setups
  93            for flight recorder (overwrite mode) live traces. One way to
  94            allow integration between NOHZ and LTTng would be to add
  95            support for such notifiers into NOHZ kernel infrastructure.
  96
  97         10) Turn drivers/staging/lttng/ltt-probes.c probe_list into a
  98             hash table. Turns O(n^2) trace systems registration (cost
  99             for n systems) into O(n). (O(1) per system)
 100
 101         11) drivers/staging/lttng/probes/lttng-ftrace.c:
 102             LTTng currently uses kretprobes for per-function tracing,
 103             not the function tracer. So lttng-ftrace.c should be used
 104             for "all" function tracing.
 105
 106         12) drivers/staging/lttng/probes/lttng-types.c:
 107             This is a currently unused placeholder to export entire C
 108             type declarations into the trace metadata, e.g. for support
 109             of describing the layout of structures/enumeration mapping
 110             along with syscall entry events.  The design of this support
 111             will likely change though, and become integrated with the
 112             TRACE_EVENT support within lttng, by adding new macros, and
 113             support for generation of metadata from these macros, to
 114             allow description of those compound types/enumerations.
 115
 116 Please send patches
 117 To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>