Project

General

Profile

Actions

Google Summer of Code 2014 » History » Revision 2

« Previous | Revision 2/17 (diff) | Next »
Jérémie Galarneau, 02/12/2014 02:59 PM


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.

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 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 for guidelines on submitting patches.
  • 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). 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

Project Ideas

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

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)

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 letting accepting rules to automatically instrument an application
Skill level: Hard
Prerequisite Knowledge: C++ development, C development, Assembly
Mentors: Christian Babeux (cbab)

Updated by Jérémie Galarneau about 10 years ago · 2 revisions