strace participation in the GSOC 2016

strace is submitting a GSOC mentor organization membership for 2016: https://summerofcode.withgoogle.com/get-started/

Program details

about strace and why you should submit your project to strace strace isa diagnostic, debugging and instructional userspace tracer for Linux. It is used to monitor interactions between processes and the Linux kernel, which include system calls, signal deliveries, and changes of process state. The operation of strace is made possible by the kernel feature known as ptrace.

strace is one of the longest running open source projects and started even before Linux started.

strace is an important tool for debugging and tracing deployed on all Linux distributions and most Unix distributions with a small community of active contributors.

While strace is a small project, the strace tool is essential for many developers, system administrators and open source projects. Its maintainers and contributors are experienced developers.

The project organization is simple: the community discusses proposed patches and a few core maintainers eventually accept or reject contributions. All contributions are submitted as git patches to the mailing list, which is the single point of communication, in a mode very similar to the ways of the Linux kernel.

strace is typically released twice per year.

Note that we are pretty laid back and cool compared to larger and professional projects like the Linux Kernel but our standards are high and the people involved in strace are die hard system coders often contributing to or maintaining major C libraries such as Glibc, Glib or Bionic, contributing to the Linux Kernel and other major free and open source projects.

So we expect that you would be making the efforts to learn our mailing list and patch ways and ask good questions and do your home work for a most productive and efficient participation.

What to do as a prospective student

We want engage with students that are interested in system programming and want to help making strace a better tool. We hope to gain you as a new long term contributor and that you will contribute interesting and new features.

You need to grok C and have an interest in system programming and debugging. The codebase is not huge but the domain is not simple and requires a meticulous attention to many details.

All the communication is going through a single mailing list: https://lists.sourceforge.net/lists/listinfo/strace-devel

Subscribe to the list, introduce yourself and start the discussion!

Please prefix your email subjects with GSOC.

~~~~ Please be kind enough to follow these simple guidelines when posting to the list:

  1. only send text emails. No HTML
  2. do not top post
  3. use and abuse the mailing list archive to see how proper discussions are handled
  4. be patient, a reply may need a week to come by
  5. use git tools to create and submit patches to the list
  6. apply to your code the same code style and indentation used overall in strace

Thank you! ~~~~

— https://sourceforge.net/p/strace/mailman/message/34924899/

Check our list of projects ideas below or submit new ideas to the list for consideration.

The best way to demonstrate your capability could be to submit a small patch ahead of the project selection for a small issue you could have identified in the codebase or a bug that has been reported.

~~~~ If you are looking for something to code that does not require deep knowledge of strace internals, there are at least two areas that come
to mind:

  1. The most popular idea that was mentioned several times in this list recently is to add a test for a syscall that's not yet covered by the test suite. See https://codecov.io/github/strace/strace for a general idea what's covered and what's not. As virtually every GSoC project expects writing some tests, the experience of extending test suite would be useful anyway.

  2. Another idea is to extend -e trace=class syntax with new classes. strace currently supports desc, file, ipc, memory, network, process, and signal. Additional classes might be useful, e.g. all open-like syscalls, all stat-like syscalls, all syscalls dealing with uid/gid, etc. This was discussed in this list already, so please see the mailing list archive. ~~~~

— https://sourceforge.net/p/strace/mailman/message/34905216/

General Proposal Requirements

You will need to submit your official proposal via https://summerofcode.withgoogle.com and plain text is the way to go. Please subscribe to the strace-devel mailing list and post your proposal there too. We expect your application to be in the range of 1000 words. Anything less than that will probably not contain enough information for us to determine whether you are the right person for the job. Your proposal should contain at least the following information, plus anything you think is relevant:

Beyond your proposal you need obviously to be familiar with C and Git (or willing to learn these two super quick).

List of project ideas for students

Comprehensive test suite Suggested by: Dmitry V. Levin

The test suite we have today is far from covering all branches of all parsers yet. According to Codecov, current test coverage is just over 50%.

The most important thing that could be done as a student project is a test suite that covers every syscall.

The goal of this project is to improve the test suite and the test coverage to a level that makes strace more reliable.

On the one hand, it would be educational for any student who is interested in syscall internals because writing syscall parsers and tests for them is the second best way to find out how syscalls work.

On the other hand, a comprehensive test suite is a prerequisite for any major change in strace source code. This test suite project does not have to be a work from scratch, there are already existing tests (e.g. strace/tests, ltp/testcases/kernel/syscalls, and sandbox/tests) that could be used as a starting point.

Structured output Suggested by: Philippe Ombredanne

Even though not too complex, parsing a strace output can be almost as involved as the strace code that encodes the output itself.

The goal of this project would be to provide a new option for a structured output in JSON or similar. This output would have a well defined structure that would make it easier to parse, so that a strace user that wants to interpret the output can focus on the interpretation of the data rather that having to handle the interpretation of the strace output first. This should help trace users write less error prone code and make strace easier to adopt. This project also includes reaching out to known open source strace output parsers creators to ensure that the new output would work out for them.

Note: there has been a project on this topic during the GSOC 2014 but it did not go all the way through the codebase. Taking over the past project, updating, streamlining the code and breaking it down in small commits that could be pushed and acceptable in the trunk would be great start.

Multi-OS and multiarch continuous tests infrastructure Suggested by: Philippe Ombredanne

The nature of strace makes it difficult to have all the tests running on all supported architectures and versions of supported OSes on a regular basis.

The goal of this project would to be setup and configure an environment for continuous testing of strace on multiple OS and architectures using available open and free resources such as the OpenSuse build service or other similar services from *nix distros, Travis CI and others, including soliciting the community to provide support for more exotic architectures test environments. With this, strace could be continuously tested on each new commit or prospective patch submission and could be released more frequently in confidence that tests are all passing.

Fault injection for syscalls Suggested by: Gabriel Laskar

Strace is basically a big pattern matcher for syscalls. It is mainly used for diagnostics and debugging purposes. But it seems that with a code base like this we could do more. We receive an event at the start and end of a syscall, and we have the possibility to cancel a syscall, and affect the output.

The basic idea is to be able to inject some faults in programs, in order to stress test them.

For example, we should be able to express that mmap() calls should fail 10% of the time. We could reuse -e option for that.

This is not a simple project, and there is multiple levels of possibilities here. This project can be greatly rewarding, as all the apis need to be designed.

Netlink socket parsers Suggested by: Gabriel Laskar

Netlink is a network protocol that is used to communicate between the kernel and the userspace. For example, iproute use netlink in order to configure the network stack (interfaces, addresses, routes, etc). It is also used by the kernel to report hotplug events to the userland.

The goal here is to add support in strace to decode netlink packet structures in order to be able to debug and discover netlink messages.

With the base ground work done, it can be easily extended to support more netlink family protocols.

GoogleSummerOfCode2016 (last edited 2018-02-26 06:05:13 by eSyr)