Google Summer of Code 2014 » History » Revision 5
Revision 4 (Jérémie Galarneau, 02/12/2014 03:02 PM) → Revision 5/17 (Jérémie Galarneau, 02/12/2014 03:03 PM)
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 inserted in the traced application’s source code. 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 amount of files to keep in the project’s tree is also greatly increased since each tracepoint has an associated header and, possibly, implementation file (.c). Recognizing the need for a more streamlined instrumentation approach, we 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. 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 supporting the definition of probes as function signatures using 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 function “create_session”, the user would invoke the tool as: <pre> 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 providers. This part of the project would also give the student a chance to contribute to other projects that are currently using DTrace to adapt their build systems and add LTTng as a supported tracing back-end. *Expected results:* TBD *Skill level:* Medium Easy-Medium *Prerequisite Knowledge:* C development, Scripting *Mentors:* Christian Babeux (cbab), Jérémie Galarneau (jgalar)