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            See: http://git.lttng.org/?p=lttng-modules.git;a=shortlog;h=refs/heads/v0.19-stable
  61                 ltt-statedump.c
  62
  63         4) Generate system call TRACE_EVENT headers for all
  64            architectures (currently done: x86 32/64).
  65
  66         5) Define "unknown" system calls into instrumentation/syscalls
  67            override files / or do SYSCALL_DEFINE improvements to
  68            mainline kernel to allow automatic generation of these
  69            missing system call descriptions.
  70
  71         6) Create missing tracepoint event headers files into
  72            instrumentation/events from headers located in
  73            include/trace/events/. Choice: either do as currently done,
  74            and copy those headers locally into the lttng driver and
  75            perform the modifications locally, or push TRACE_EVENT API
  76            modification into mainline headers, which would require
  77            collaboration from Ftrace/Perf maintainers.
  78
  79         7) Poll: implement a poll and/or epoll exclusive wakeup scheme,
  80            which contradicts POSIX, but protect multiple consumer
  81            threads from thundering herd effect.
  82
  83         8) Re-integrate sample modules from libringbuffer into
  84            lttng driver. Those modules can be used as example of how to
  85            use libringbuffer in other contexts than LTTng, and are
  86            useful to perform benchmarks of the ringbuffer library.
  87            See: http://www.efficios.com/ringbuffer
  88
  89         9) NOHZ support for lib ring buffer. NOHZ infrastructure in the
  90            Linux kernel does not support notifiers chains, which does
  91            not let LTTng play nicely with low power consumption setups
  92            for flight recorder (overwrite mode) live traces. One way to
  93            allow integration between NOHZ and LTTng would be to add
  94            support for such notifiers into NOHZ kernel infrastructure.
  95
  96         10) Turn lttng-probes.c probe_list into a
  97             hash table. Turns O(n^2) trace systems registration (cost
  98             for n systems) into O(n). (O(1) per system)
  99
 100         11) drivers/staging/lttng/probes/lttng-ftrace.c:
 101             LTTng currently uses kretprobes for per-function tracing,
 102             not the function tracer. So lttng-ftrace.c should be used
 103             for "all" function tracing.
 104
 105         12) drivers/staging/lttng/probes/lttng-types.c:
 106             This is a currently unused placeholder to export entire C
 107             type declarations into the trace metadata, e.g. for support
 108             of describing the layout of structures/enumeration mapping
 109             along with syscall entry events.  The design of this support
 110             will likely change though, and become integrated with the
 111             TRACE_EVENT support within lttng, by adding new macros, and
 112             support for generation of metadata from these macros, to
 113             allow description of those compound types/enumerations.
 114
 115 Please send patches
 116 To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>