Differences between revisions 1 and 2
Revision 1 as of 2018-02-26 06:10:35
Size: 8423
Editor: eSyr
Comment:
Revision 2 as of 2018-09-02 12:45:48
Size: 8605
Editor: eSyr
Comment: convert to moin markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#format text_markdown == strace participation in the GSOC 2014 ==
Line 3: Line 3:
__strace participation in the GSOC 2014__

strace
has been accepted as a GSOC project for 2014:
`strace` has been accepted as a GSOC project for 2014:
Line 9: Line 7:
___Accepted projects and participants___ === Accepted projects and participants ===
Line 11: Line 9:
 * [Gsoc2014StructuredJsonOutput] with YangMin Zhu
 * [Gsoc2014AdvancedAbsolutePathsDecoding] with Zubin Mithra
 * [Gsoc2014SecurityEnhancements] with Zubin Mithra
 * [Gsoc2014ImprovedMultiArchitectureSupport] with Edson Ticona
 * [[Gsoc2014StructuredJsonOutput]] with YangMin Zhu
 * [[Gsoc2014AdvancedAbsolutePathsDecoding]] with Zubin Mithra
 * [[Gsoc2014SecurityEnhancements]] with Zubin Mithra
 * [[Gsoc2014ImprovedMultiArchitectureSupport]] with Edson Ticona
Line 17: Line 15:
== Program details ==
Line 18: Line 17:
__Program details __ === about strace and why you should submit your project to strace ===
Line 20: Line 19:
`strace` is a system call tracer, i.e. a debugging tool which prints out a trace of all the system calls made by another process/program.
Line 21: Line 21:
___about strace and why you should submit your project to strace___
strace is a system call tracer, i.e. a debugging tool which prints out a trace of all the system calls made by another process/program.
`strace` is one of the longest running open source projects and started even before Linux started.
Line 24: Line 23:
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.
Line 26: Line 25:
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.
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.
Line 32: Line 29:
strace is typically released once per year. `strace` is typically released once per year.
Line 35: Line 32:
=== What to do as a prospective student ===
Line 36: Line 34:
___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.
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.
Line 44: Line 39:
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 56: Line 50:
___ General Proposal Requirements ___ === General Proposal Requirements ===
Line 59: Line 53:
Please subscribe to the strace-devl mailing list and post your proposal there too. Please subscribe to the strace-devel mailing list and post your proposal there too.
Line 62: Line 56:
* Your name
* Title of your proposal
* Abstract of your proposal
* Detailed description of your idea including explanation on why is it innovative
* 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?
* 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?
 * Your name
 * Title of your proposal
 * Abstract of your proposal
 * Detailed description of your idea including explanation on why is it innovative
 * 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?
 * 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?
Line 76: Line 69:
___List of project ideas for students___ == List of project ideas for students ==
Line 78: Line 71:
__Reliable multiarchitecture support__
Suggested by: Dmitry V. Levin
=== Reliable multiarchitecture support ===
''Suggested by:'' [[DmitryLevin|Dmitry V. Levin]]
Line 81: Line 74:
The way multiarchitecture support (simultaneous tracing of processes with different personalities, e.g. x86-64/x32/x86) is implemented in strace for now is inherently unreliable. The way multiarchitecture support (simultaneous tracing of processes with different personalities, e.g. x86-64/x32/x86) is implemented in `strace` for now is inherently unreliable.
Line 84: Line 77:
The goal of this project would to improve the way multiarchitecture is handled by strace, to simplify the code and parsers. The goal of this project would to improve the way multiarchitecture is handled by `strace`, to simplify the code and parsers.
Line 87: Line 80:
__Comprehensive test suite__
Suggested by: Dmitry V. Levin
=== Comprehensive test suite ===
''Suggested by:'' [[DmitryLevin|Dmitry V. Levin]]
Line 95: Line 88:
__Structured output__
Suggested by: Philippe Ombredanne
=== Structured output ===
''Suggested by:'' [[GitHub:pombredanne|Philippe Ombredanne]]
Line 98: Line 91:
Even though not too complex, parsing a strace output can be almost as involved as the strace code that encodes the output itself. Even though not too complex, parsing a `strace` output can be almost as involved as the `strace` code that encodes the output itself.
Line 100: Line 93:
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. 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.
Line 103: Line 96:
__Multi-OS and multiarch continuous tests infrastructure__
Suggested by: Philippe Ombredanne
=== Multi-OS and multiarch continuous tests infrastructure ===
''Suggested by:'' [[GitHub:pombredanne|Philippe Ombredanne]]
Line 106: Line 99:
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 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.
Line 108: Line 101:
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. 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.
Line 110: Line 103:
__Downstream patches roundup and ushering__
Suggested by: Philippe Ombredanne
=== Downstream patches roundup and ushering ===
''Suggested by:'' [[GitHub:pombredanne|Philippe Ombredanne]]
Line 113: Line 106:
Strace is reused in several *nix distro. These downstream projects track patches and bugs and these may not be always visible to the strace community and maintainers. `strace` is reused in several *nix distro. These downstream projects track patches and bugs and these may not be always visible to the `strace` community and maintainers.
Line 115: Line 108:
The goal of this project would to review available patches and bugs from the key downstream maintainers and either contribute these as patches to strace when relevant or work with the downstream maintainers to contribute their patches back to strace. Ideally mini tools should be created to collect these bugs and patches automatically on a regular basis to inform the strace community of bugs and conversation happening elsewhere than on the strace mailing list. The goal of this project would to review available patches and bugs from the key downstream maintainers and either contribute these as patches to `strace` when relevant or work with the downstream maintainers to contribute their patches back to `strace`. Ideally mini tools should be created to collect these bugs and patches automatically on a regular basis to inform the `strace` community of bugs and conversation happening elsewhere than on the `strace` mailing list.
Line 117: Line 110:
__Advanced and improved absolute paths decoding__
Suggested by: Philippe Ombredanne
=== Advanced and improved absolute paths decoding ===
''Suggested by:'' [[GitHub:pombredanne|Philippe Ombredanne]]
Line 120: Line 113:
strace can decode file descriptor path arguments with the -y option. There are other areas where paths decoding could be improved such as decoding an absolute for a relative path, or decoding a file descriptor returned as a call return code. Interpreting paths-related arguments that are not decoded requires today to know and track the cwd (current working directory) when parsing a strace output. If all paths could optionally be returned as decoded absolute paths, such tracking and interpretation would not be needed. `strace` can decode file descriptor path arguments with the `-y` option. There are other areas where paths decoding could be improved such as decoding an absolute for a relative path, or decoding a file descriptor returned as a call return code. Interpreting paths-related arguments that are not decoded requires today to know and track the cwd (current working directory) when parsing a `strace` output. If all paths could optionally be returned as decoded absolute paths, such tracking and interpretation would not be needed.
Line 122: Line 115:
The goal of this project would be to provide advanced and improved path decoding in these cases: for call arguments that are about paths that depend on the cwd (such as open, rename and more) or depend on a file descriptor/path combos (such as openat, renameat and more) and/or for calls that return a file descriptor (such as open). The end results should be possibly a new option (possibly -yy) and its effects would be that all paths or descriptors are decoded to absolute paths wherever they appear in calls. This could also include better socket descriptors decoding such that actual address, protocol and ports are known. See some posts for more details: https://sourceforge.net/p/strace/mailman/search/?q=Advanced+and+improved+absolute+paths+decoding The goal of this project would be to provide advanced and improved path decoding in these cases: for call arguments that are about paths that depend on the cwd (such as open, rename and more) or depend on a file descriptor/path combos (such as openat, renameat and more) and/or for calls that return a file descriptor (such as open). The end results should be possibly a new option (possibly `-yy`) and its effects would be that all paths or descriptors are decoded to absolute paths wherever they appear in calls. This could also include better socket descriptors decoding such that actual address, protocol and ports are known. See some posts for more details: https://sourceforge.net/p/strace/mailman/search/?q=Advanced+and+improved+absolute+paths+decoding

strace participation in the GSOC 2014

strace has been accepted as a GSOC project for 2014: https://www.google-melange.com/gsoc/org2/google/gsoc2014/strace

Accepted projects and participants

Program details

about strace and why you should submit your project to strace

strace is a system call tracer, i.e. a debugging tool which prints out a trace of all the system calls made by another process/program.

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 once per year.

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.

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.

General Proposal Requirements

You will need to submit your official proposal via https://www.google-melange.com/gsoc/homepage/google/gsoc2014 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
  • 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?
  • 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?

Beyond your proposal you need obviously to be familiar with C and Git (or willing to lean Git quick).

List of project ideas for students

Reliable multiarchitecture support

Suggested by: Dmitry V. Levin

The way multiarchitecture support (simultaneous tracing of processes with different personalities, e.g. x86-64/x32/x86) is implemented in strace for now is inherently unreliable. Instead, parsers should be compiled natively for each supported personality.

The goal of this project would to improve the way multiarchitecture is handled by strace, to simplify the code and parsers.

Comprehensive test suite

Suggested by: Dmitry V. Levin

The test suite we have today is far from covering all branches of all parsers yet.

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

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.

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.

Downstream patches roundup and ushering

Suggested by: Philippe Ombredanne

strace is reused in several *nix distro. These downstream projects track patches and bugs and these may not be always visible to the strace community and maintainers.

The goal of this project would to review available patches and bugs from the key downstream maintainers and either contribute these as patches to strace when relevant or work with the downstream maintainers to contribute their patches back to strace. Ideally mini tools should be created to collect these bugs and patches automatically on a regular basis to inform the strace community of bugs and conversation happening elsewhere than on the strace mailing list.

Advanced and improved absolute paths decoding

Suggested by: Philippe Ombredanne

strace can decode file descriptor path arguments with the -y option. There are other areas where paths decoding could be improved such as decoding an absolute for a relative path, or decoding a file descriptor returned as a call return code. Interpreting paths-related arguments that are not decoded requires today to know and track the cwd (current working directory) when parsing a strace output. If all paths could optionally be returned as decoded absolute paths, such tracking and interpretation would not be needed.

The goal of this project would be to provide advanced and improved path decoding in these cases: for call arguments that are about paths that depend on the cwd (such as open, rename and more) or depend on a file descriptor/path combos (such as openat, renameat and more) and/or for calls that return a file descriptor (such as open). The end results should be possibly a new option (possibly -yy) and its effects would be that all paths or descriptors are decoded to absolute paths wherever they appear in calls. This could also include better socket descriptors decoding such that actual address, protocol and ports are known. See some posts for more details: https://sourceforge.net/p/strace/mailman/search/?q=Advanced+and+improved+absolute+paths+decoding

GoogleSummerOfCode2014 (last edited 2018-09-02 12:45:48 by eSyr)