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