Differences between revisions 1 and 6 (spanning 5 versions)
Revision 1 as of 2018-02-26 06:03:44
Size: 10156
Editor: eSyr
Comment: initial import
Revision 6 as of 2018-03-09 21:30:33
Size: 11422
Editor: eSyr
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#format text_markdown = Google Summer of Code 2018 =
Line 3: Line 3:
[__ strace is taking part in the GSoC 2018 as a mentor organization. __](https://summerofcode.withgoogle.com/organizations/5733913570312192/) '''[[https://summerofcode.withgoogle.com/organizations/5733913570312192/|strace is taking part in the GSoC 2018 as a mentor organization]].'''
Line 5: Line 5:
About strace project.
--
strace is a diagnostic, debugging and instructional userspace tracer for Linux. It is used to monitor and tamper with 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](http://man7.org/linux/man-pages/man2/ptrace.2.html).
Line 9: Line 6:
strace is one of the longest running open source projects and started even before Linux started. == About strace project. ==

strace is a diagnostic, debugging and instructional userspace tracer for Linux. It is used to monitor and tamper with 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 [[http://man7.org/linux/man-pages/man2/ptrace.2.html|ptrace]].

strace is one of the longest running open source projects and had been started even before Linux was started.
Line 24: Line 25:
What to do as a prospective student.
--
== What to do as a prospective student ==
Line 32: Line 32:
All the communication is going through a single mailing list: https://lists.sourceforge.net/lists/listinfo/strace-devel All the communication is going through a single mailing list: https://lists.strace.io/mailman/listinfo/strace-devel
Line 38: Line 38:
~~~~ {{{
Line 49: Line 49:
~~~~
— https://sourceforge.net/p/strace/mailman/message/34924899/
}}}
— https://lists.strace.io/pipermail/strace-devel/2016-March/004704.html
Line 54: Line 54:
It is required that students who want to apply to the strace project for the GSoC 2018 complete a relatively small code-related "microproject" as part of their application. Please refer to our guidelines and suggestions for [Microprojects] for more information. Completing a microproject is not only an important way for us to get experience with applicants, but it will also help applicants become familiar with strace's development and submission process. It is required that students who want to apply to the strace project for the GSoC 2018 complete a relatively small code-related "microproject" as part of their application. Please refer to our guidelines and suggestions for MicroProjects for more information. Completing a microproject is not only an important way for us to get experience with applicants, but it will also help applicants become familiar with strace's development and submission process.
Line 56: Line 56:
General Proposal Requirements.
--
== General proposal requirements ==
Line 60: Line 59:
Line 61: Line 61:
Line 63: Line 64:
* Your name
* Title of your proposal
* Abstract of your proposal
* Detailed description of your idea including explanation on why is it innovative and what it will contribute
* Description of previous work, existing solutions (links to prototypes, bibliography are more than welcome)
* Mention the details of your academic studies, any previous work, internships
* Any relevant skills that will help you to achieve the goal (programming languages, frameworks)?
* Any previous open-source projects (or even previous GSoC) you have contributed to?
* Any open-source code of yours that we can check out?
* Do you plan to have any other commitments during SoC that may affect you work? Any vacations/holidays planned? Will you be available full time to work on your project? (Hint: do not bother applying if this is not a serious full time commitment)
 * Your name
 * Title of your proposal
 * Abstract of your proposal
 * Detailed description of your idea including explanation on why is it innovative and what it will contribute
 * Description of previous work, existing solutions (links to prototypes, bibliography are more than welcome)
 * Mention the details of your academic studies, any previous work, internships
 * Any relevant skills that will help you to achieve the goal (programming languages, frameworks)?
 * Any previous open-source projects (or even previous GSoC) you have contributed to?
 * Any open-source code of yours that we can check out?
 * Do you plan to have any other commitments during SoC that may affect you work? Any vacations/holidays planned? Will you be available full time to work on your project? (Hint: do not bother applying if this is not a serious full time commitment)
Line 76: Line 77:
List of project ideas for students.
--
== List of project ideas for students ==
Line 79: Line 79:
__ Comprehensive test suite. __
Suggested by: Eugene Syromyatnikov, Dmitry V. Levin
=== Comprehensive test suite ===
''Suggested by:'' [[eSyr|Eugene Syromyatnikov]], [[DmitryLevin|Dmitry V. Levin]]
Line 83: Line 83:
According to [Codecov](https://codecov.io/github/strace/strace), current test coverage is just over 80%, but it tells very little about coverage of various corner cases (checks for type sizes, signedness, handling of pointers to invalid memory, etc). According to [[https://codecov.io/github/strace/strace|Codecov]], current test coverage is just over 80%, but it tells very little about the actual coverage of various corner cases (checks for type sizes, signedness, handling of pointers to invalid memory, etc).
Line 92: Line 92:
__ Support for alternative tracing backends __
Suggested by: Eugene Syromyatnikov
=== Support for alternative tracing backends ===
''Suggested by:'' [[eSyr|Eugene Syromyatnikov]]
Line 98: Line 98:

* [Original work by Josh Stone](https://github.com/cuviper/strace/)
* [Current state by Stanford Cox](https://github.com/stanfordcox/strace/commits/gdbserver0)
* [Preparational patches that include initial backend support](https://github.com/esyr-rh/strace/commits/gdbserver-prep)
* [gdbserver backend proposal letter](https://sourceforge.net/p/strace/mailman/strace-devel/thread/d967f64d-7660-3d45-7d2b-dfbd2cba54fe%40redhat.com/#msg35598297)
 * [[https://github.com/cuviper/strace/|Original work by Josh Stone]]
 * [[https://github.com/stanfordcox/strace/commits/gdbserver0|Current state by Stanford Cox]]
 * [[https://github.com/esyr-rh/strace/commits/gdbserver-prep|Preparational patches that include initial backend support]]
 * [[https://lists.strace.io/pipermail/strace-devel/2017-January/005915.html|gdbserver backend proposal letter]]
Line 105: Line 104:
 * [[https://github.com/pmem/vltrace|vltrace]]
 * [[https://devconfcz2018.sched.com/event/DJYj/stracing-using-perf-and-ebpf|"stracing using pers and eBPF" talk by Arnaldo Carvalho de Melo]]
 * [[http://vger.kernel.org/~acme/perf/linuxdev-br-2017.pdf|"News from tools/perf land: What has been brewing in the Linux observability tools" by Arnaldo Carvalho de Melo]]
Line 106: Line 108:
* [vltrace](https://github.com/pmem/vltrace)
* ["stracing using pers and eBPF" talk by Arnaldo Carvalho de Melo](https://devconfcz2018.sched.com/event/DJYj/stracing-using-perf-and-ebpf)
* ["News from tools/perf land: What has been brewing in the Linux observability tools" by Arnaldo Carvalho de Melo](http://vger.kernel.org/~acme/perf/linuxdev-br-2017.pdf)
=== seccomp-assisted syscall filtering ===
''Suggested by:'' [[DmitryLevin|Dmitry Levin]]
Line 110: Line 111:
__ seccomp-assisted syscall filtering. __
Suggested by: Dmitry Levin

SECCOMP_RET_TRACE seccomp API could be used to implement a more efficient syscall filtering.
`SECCOMP_RET_TRACE` seccomp API could be used to implement a more efficient syscall filtering.
Line 116: Line 114:
There was a (seemingly abandoned) attempt made at some point: https://github.com/shinh/strace/commit/92db747699773b8b9be42ecb27ab969eeb649825 There [[https://github.com/shinh/strace/commit/92db747699773b8b9be42ecb27ab969eeb649825|was]] a (seemingly abandoned) attempt made at some point.
Line 118: Line 116:
__ DRM ioctl decoding __
Suggested by: Eugene Syromyatnikov
=== DRM ioctl decoding ===
''Suggested by:'' [[eSyr|Eugene Syromyatnikov]]
Line 123: Line 121:
* [Some patch proposal](https://lists.freedesktop.org/archives/intel-gfx/2015-August/074249.html)
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_ioctl.c
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_ioc32.c
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/i915_drv.c#n2717
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c#n1016
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c#n929
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/exynos/exynos_drm_drv.c#n101
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i810/i810_dma.c#n1241
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/mga/mga_state.c#n1086
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nouveau_drm.c#n1001
 * [[https://lists.freedesktop.org/archives/intel-gfx/2015-August/074249.html|Some patch proposal]]
 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_ioctl.c
 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_ioc32.c
 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/i915_drv.c#n2717
 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c#n1016
 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c#n929
 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/exynos/exynos_drm_drv.c#n101
 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i810/i810_dma.c#n1241
 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/mga/mga_state.c#n1086
 * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nouveau_drm.c#n1001
Line 134: Line 132:
__ namespace support __
Suggested by: Eugene Syromyatnikov
=== namespace support ===
''Suggested by:'' [[eSyr|Eugene Syromyatnikov]]
Line 137: Line 135:
It could be useful to be able to show PIDs of processes in different PID namespaces when they are shown up in syscall arguments and results: It could be useful to be able to show PIDs of processes in different PID namespaces when they are shown up in syscall arguments and results. As of now, this is quite complicated by the fact that there's no way to easily derive PID of the target process in the strace's namespace.
Line 139: Line 137:
* [RH bug](https://bugzilla.redhat.com/show_bug.cgi?id=1035433)  * [[https://bugzilla.redhat.com/show_bug.cgi?id=1035433|RH bug]]
 * [[https://lkml.org/lkml/2017/10/13/177|LKML thread]] with a patch that introduces a syscall that helps translating PIDs between PID namespaces
 * [[https://github.com/esyr-rh/strace/commits/esyr/ns|Some WiP]]
Line 141: Line 141:
The other thing is the preservation of correctness of various strace features (path filtering, fd decoding, thread enumeration, ...) that rely on /proc when the traced process is in different namespace. The other thing is the preservation of correctness of various strace features (path filtering, fd decoding, thread enumeration, ...) that rely on `/proc` when the traced process is in different namespace.
Line 143: Line 143:
__Other ideas__ === Adding Doxygen documentation of the internall APIs ===
''Suggested by:'' Elvira Khabirova, [[eSyr|Eugene Syromyatnikov]]

Over the years, strace's internal APIs used for various purposes (like printing various entities) have been grown significantly, to the point it leads to duplication of the code (for example, printing of hexadecimal strings is duplicated now in `v4l2.c`, `btrfs.c` and `util.c`). The other issue with the vast internal API (which is usually the result of long history of handling various issues with various architectures and version of the Linux kernel) is that it's not self-evident how things should be done properly. It's believed that documenting current APIs could lower the learning curve and increase overall quality of the code.

=== Other ideas ===

Google Summer of Code 2018

strace is taking part in the GSoC 2018 as a mentor organization.

About strace project.

strace is a diagnostic, debugging and instructional userspace tracer for Linux. It is used to monitor and tamper with 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 had been started even before Linux was 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 release cycle is currently synchronized with the release cycle of the Linux kernel.

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.strace.io/mailman/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://lists.strace.io/pipermail/strace-devel/2016-March/004704.html

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

It is required that students who want to apply to the strace project for the GSoC 2018 complete a relatively small code-related "microproject" as part of their application. Please refer to our guidelines and suggestions for MicroProjects for more information. Completing a microproject is not only an important way for us to get experience with applicants, but it will also help applicants become familiar with strace's development and submission process.

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:

  • Your name
  • Title of your proposal
  • Abstract of your proposal
  • Detailed description of your idea including explanation on why is it innovative and what it will contribute
  • Description of previous work, existing solutions (links to prototypes, bibliography are more than welcome)
  • Mention the details of your academic studies, any previous work, internships
  • Any relevant skills that will help you to achieve the goal (programming languages, frameworks)?
  • Any previous open-source projects (or even previous GSoC) you have contributed to?
  • Any open-source code of yours that we can check out?
  • Do you plan to have any other commitments during SoC that may affect you work? Any vacations/holidays planned? Will you be available full time to work on your project? (Hint: do not bother applying if this is not a serious full time commitment)

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: Eugene Syromyatnikov, 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 80%, but it tells very little about the actual coverage of various corner cases (checks for type sizes, signedness, handling of pointers to invalid memory, etc).

The goal of this project is to improve the test suite 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.

Support for alternative tracing backends

Suggested by: Eugene Syromyatnikov

Add support for providing various backends for strace.

There is one backend already in development (gdbserver), but it's still not finished:

There is also an idea that uprobes/kprobes/ftrace/perf can be utilized for tracing syscalls as a more modern way of tracing processes, which makes the possible support for various tracing backend more useful.

seccomp-assisted syscall filtering

Suggested by: Dmitry Levin

SECCOMP_RET_TRACE seccomp API could be used to implement a more efficient syscall filtering. Using this technique, tracees will be stopped on entering filtered syscalls only instead of all syscalls.

There was a (seemingly abandoned) attempt made at some point.

DRM ioctl decoding

Suggested by: Eugene Syromyatnikov

Direct Rendering Manager subsystem has pretty elaborate ioctl interface, and it might be useful to be able to support its decoding.

namespace support

Suggested by: Eugene Syromyatnikov

It could be useful to be able to show PIDs of processes in different PID namespaces when they are shown up in syscall arguments and results. As of now, this is quite complicated by the fact that there's no way to easily derive PID of the target process in the strace's namespace.

The other thing is the preservation of correctness of various strace features (path filtering, fd decoding, thread enumeration, ...) that rely on /proc when the traced process is in different namespace.

Adding Doxygen documentation of the internall APIs

Suggested by: Elvira Khabirova, Eugene Syromyatnikov

Over the years, strace's internal APIs used for various purposes (like printing various entities) have been grown significantly, to the point it leads to duplication of the code (for example, printing of hexadecimal strings is duplicated now in v4l2.c, btrfs.c and util.c). The other issue with the vast internal API (which is usually the result of long history of handling various issues with various architectures and version of the Linux kernel) is that it's not self-evident how things should be done properly. It's believed that documenting current APIs could lower the learning curve and increase overall quality of the code.

Other ideas

We are also open to any suggestions not listed on this page.

Some existing ideas are present on a [separate page](FeatureRequests). Note, however, that they may be not adequately sized for a GSoC project or require specific qualifications.

GoogleSummerOfCode2018 (last edited 2021-02-19 10:41:43 by DmitryLevin)