LTTng

h1. Google Summer of Code 2014

Google Summer of Code is a global program that offers students stipends to write code for open source projects. 

Following a great first experience last year, the LTTng project will participate in GSoC for a second year.

h1. Guidelines for students applying to GSoC

Here a few guidelines and advice for aspiring applicants to GSoC:

* *Submit* your application to Google by *March 21 2014 19:00 UTC*.

* *Join* the IRC #lttng channel on OFTC (irc://irc.oftc.net/lttng) to discuss your application and project ideas.

  Since IRC and the "mailing list":http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev are our usual means of communications, applicants who have shown initiative in communicating with the community will be favored during the applications review. Please refer to the "Contributor''s guide":http://raw.github.com/jgalar/lttng-doc/master/contributor-guide.txt for guidelines on submitting patches.

* *Subscribe* to the lttng-dev "mailing list":http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev.

* *Break the ice!* Try submitting a patch for simple issues such as typos, documentation improvements, simple bug fixes (a good starting point would be to look at the LTTng bug tracker: "issues":http://bugs.lttng.org/projects/lttng/issues?sort=priority%2Cid%3Adesc). Or you could try the complete toolchain on some of your personal projects and come up with a problematic situation (performance issue, ease of debugging, etc.) that *your* project idea could potentially solve. Perhaps you have ideas to improve LTTng''s usability? Discuss them with us, you might just have found yourself a summer project! 

* *Don''t panic!* Some portions of the LTTng project can be quite complex and technically challenging; we don''t expect applicants to be familiar with all the concepts behind the LTTng codebase.

Additional tips for a successful application: "The DOs and DON’Ts of Google Summer of Code: Student Edition":http://google-opensource.blogspot.de/2011/03/dos-and-donts-of-google-summer-of-code.html

h1. Project Ideas

The following ideas are only a starting point for applicants. Feel free to submit your own project idea!

h2. Android port

*Brief explanation*:

Port the LTTng infrastructure to the Android platform. The exact scope of this project will need to be reassessed based on the conclusions of the team currently working on this project as part of their undergrad project at École Polytechnique de Montréal.

This project presents a number of uncertain technical hurdles but some effort has already been made in most key areas.

* The userspace part of the LTTng project relies on glibc features not present in Bionic -- Google''s libc implementation used on Android.

  - Glibc is now available on Android thanks to the efforts made by the cyborgstack project.

* System V IPC mechanisms are heavily relied-upon.

  - The Ericsson port makes use of temporary files.

  - Glibc on Android should provide such mechanisms.

* Userspace RCU must be ported and tested on the Android platform.

  - Ported by Ericsson, not mainlined.

*Expected results*: A working port of LTTng''s tracers running on an Android device.

*Complementary information*:

http://lists.lttng.org/pipermail/lttng-dev/2012-February/017626.html

*Skill level*: Hard

*Prerequisite Knowledge*: C development, Android development

*Mentors*: Christian Babeux (cbab), Jérémie Galarneau (jgalar)

h2. Clang plugin providing automatic application instrumentation

*Brief explanation:*

The LTTng userspace tracer relies on static tracepoint probes manually inserted in the traced application’s source code. This project aims at developing a compiler plugin that would automatically instrument an application at build time following a set of criteria.

At this time, LTTng provides only one solution to the automatic instrumentation problem. By using GCC and LLVM’s -finstrument-functions code generation option and LTTng’s cyg-profile library, it is possible for developers to trace every function entry and exit in their program. While this has proved useful in the past, this mechanism introduces a significant amount of overhead.

A more refined automatic instrumentation solution is necessary to uphold LTTng’s objective of providing a low-intrusiveness tracing solution. A compiler plugin seems to be one of the most flexible solution to this problem. Such a plug-in could allow the instrumentation of functions whose name match a certain expression, instrumentation of all calls made to a particular library, instrumentation of functions listed in a separate file, etc.

A natural extension of this project is the development of analysis scripts using the Babeltrace Python API to detect resource leaks, dead code, hot paths and so on.

*Expected results:* A compiler plugin processing rules to automatically instrument an application at build time.

*Skill level:* Hard

*Prerequisite Knowledge:* C++ development, C development, Assembly

*Mentors:* Christian Babeux (cbab)

h2. Easing the integration of tracepoints in user space applications

*Brief explanation:*

The LTTng userspace tracer relies on static tracepoint probes manually added to an application’s source code to generate events.

The currently privileged instrumentation method consists in creating a C header which contains a description of an LTTng event and declares a tracepoint. This header is then included by the application developer and called the same way a function would.

These tracepoint provider headers contain a significant amount of boilerplate code and impose a maintenance cost which is considered unreasonable by certain application developers. The number of files to manage in the project’s tree is also significantly increased since each tracepoint has an associated header and, possibly, implementation file (.c).

We acknowledge the need for a more streamlined instrumentation approach and now ship the lttng-gen-tp script as part of lttng-tools. This script can be used to generate the necessary tracepoint headers and implementation files but still requires the developer to manually create tracepoint declaration files.

Numerous discussions with developers have led us to propose a certain number of improvements to lttng-gen-tp as a Google Summer of Code project.

The first improvement we propose is adding support for the definition of probes as function signatures containing only built-in types.

A slightly more advanced feature would let developers specify which variables they wish to trace. The tool would then analyze the source code and create the appropriate probe signature from the type information. For instance, to create a tracepoint logging variables “session”, “ret” and “len” in a “create_session” function, the user would invoke the tool as:

<pre>

lttng-gen-tp -a session, ret, len -f create-session -i my_file.c -n my_tracepoint_name

</pre>

Finally, we would like to leverage the existing DTrace probe infrastructures currently deployed in some open source projects such as Node.js and PostgreSQL as LTTng tracepoints. This part of the project would also give the student a chance to contribute to other open source projects that are currently using DTrace to adapt their build systems and add LTTng as a supported tracing back-end.

*Expected results:* An overhauled version of the lttng-gen-tp tool providing multiple ways of assisting developers in the addition of LTTng tracepoints to their application.

*Skill level:* Medium

*Prerequisite Knowledge:* C development, Scripting

*Mentors:* Christian Babeux (cbab), Jérémie Galarneau (jgalar)

h2. Strace drop-in replacement based on LTTng

*Brief explanation:*

Strace:http://en.wikipedia.org/wiki/Strace is a ptrace-based debugging utility which lets developers trace syscalls and signals as they occur during a process’ lifetime. With the addition of live tracing and save-and-restore features, we are confident that it would be possible to build a tool that combines both LTTng’s performance characteristics and strace’s ease of use.

The objective of this project is the development of a tool that would automatically setup tracing sessions, implement a live streaming client based on Babelltrace’s live support and provide the same UI as strace.

A number of extensions could then be added to this tool such as trace saving capabilities, extended support to display userspace events, kernel event support, etc.

*Expected results:* An strace drop-in replacement based on LTTng

*Skill level:* Medium

*Prerequisite Knowledge:* C development

*Mentors:* Christian Babeux (cbab), Jérémie Galarneau (jgalar)

h2. Python tracing support

*Brief explanation:*

LTTng’s userspace tracer has supported C applications from its onset. However, as our user base broadens, we have added user space tracing support for both C++ and Java applications. We think the next logical step is Python as our team already has experience in this language and is becoming increasingly familiar with the development of Python code binding to C libraries.

A student choosing this project would integrate a new Python domain to lttng-tools, develop a generic probe provider and add support for LTTng among the standard Python logging infrastructure.

We think this project serves as a great introduction to the complete LTTng toolchain and would be a great fit for students looking for long-term involvement in an open source project.

*Expected results:* Integration of LTTng amongst Python''s logging infrastructure.

*Complementary information:* "Python Logging Documentation":http://docs.python.org/3.3/library/logging.html

*Skill level:* Medium

*Prerequisite Knowledge:* C and Python development

*Mentors:* Christian Babeux (cbab), Jérémie Galarneau (jgalar)