Buildroot:GSoC2016Ideas

From eLinux.org
Revision as of 16:33, 9 February 2016 by Arnout Vandecappelle (talk | contribs) (Reproducible builds: Extend description a bit, refer to reproducible-builds.org)
Jump to: navigation, search

2016 will be the third year of participation of Buildroot to the Google Summer of Code program. This year, we are proposing the following ideas.

Mentors

The following people will be your mentors. Each topic is assigned a mentor, who will be your referent and will follow you during the GSoC. However, all mentors will be available to help you.

  • Arnout Vandecappelle
  • Peter Korsgaard
  • Romain Naour
  • Thomas Petazzoni
  • Yann E. MORIN

(Detailed contact information will be added shortly.)

Topics

The following topics are suggested by the Buildroot developers; they are not sorted in any specific order, not even of preference. Feel free to propose your own ideas.

(Detailed descriptions will be added shortly.)

Reproducible builds

Mentor: Yann E. MORIN

Short: Ensure that two runs of Buildroot with the same configuration yield the same result.

Abstract

A very important feature of a build system is to provide reproducible builds. Reproducible builds means that, given the same inputs, multiple builds of the same source will generate identical output, even when they are executed on different machines, at different times, in different locations, by different users. It is then possible to assess and independently verify that the source code is indeed what was used to generate a binary. It is then also guaranteed that a developer build and an automatic production build yield the same results.

Description

We would like to assess how reproducible the builds made by Buildroot are, identify and fix all the sources for non-reproducibility. This will involve creating an infrastructure to run builds twice and compare the results, and provide tools to identify the reasons for the differences. Finally, when possible, fix the source of the differences.

Reproducible builds are a hot topic, there is [https://reproducible-builds.org/ an entire website] dedicated to it.

Skills

  • Intermediate Embedded Linux knowledge (cross-compilation, ELF format...)
  • Knowledge in the Python scripting language (existing testing infrastructure is written in Python, so it makes sense to continue in Python)
  • Knowledge of tools like Jenkins would be a plus.

Testing infrastructure

Mentor: Thomas Petazzoni

Short: Improve upon the existing testing infrastructures, build-time and runtime tests.

Abstract

The Buildroot project uses automated testing to help validate the stability of the project. There are currently two types of automated testing:

  • random configurations are used to help validate that the millions of possible Buildroot configurations build correctly. This automated build testing has been running for about three years (results visibles at [1]),
  • regression testing of a set of known configurations is used to track the sample configurations for a set of commonly-available embedded boards (Beagle Bone, Raspberry Pi, Wandboard...). This regression testing has been running for a few months now as a test-bed and now reports build results every other days.

These testing infrastructure have helped improve the quality of Buildroot. However, the project would like to bring a number of improvements to the random configuration testing infrastructure.

Description

We would like to add runtime testing, i.e really boot the generated system under Qemu, and verify, for the different packages that are part of the system, that they at least minimally work. For example, if the Python interpreter has been selected to be part of the system, verify that we can run it, and run a simple Python test application on the target. This involves creating an infrastructure to start Qemu, run tests inside Qemu, and report the results in a database. The tests would have to be integrated in the Buildroot packages themselves.

Skills

  • Basic Embedded Linux knowledge (cross-compilation, kernel configuration/build, etc.)
  • Knowledge of the Python scripting language, used for the development of the testing infrastructure.
  • Some Web development skills and/or knowledge of tools like Jenkins would be a plus.

Relocatable SDK

Mentor: Yann E. MORIN

Short: Make the generated toolchain and staging relocatable.

Top-level parallel build

Mentor: Arnout Vandecapelle

Short: Allow a full top-level, concurrent, parallel build of packages.

Abstract

Building a complete system from source can take a long time. Most packages can be built in parallel, and Buildroot takes advantage of this to shorten the build time. However, Buildroot can only build one package at a time; parallelism is only used at the package level, which is not not optimally making use of the available resources. In particular, the configure steps of most packages are only sequential, and they can take quite a large part of the build.

Description

We would like for Buildroot to be able to build in parallel at the top-level, i.e. be able to build different packages concurrently, to maximise the use of the available CPU resources and consequently decrease the build time. This will require changes deep in the core of Buildroot and how we store and use the generated artifacts (staging, host tools...). The dependencies between packages will have to be investigated, to detect implicit dependencies (i.e. implicit or optional dependencies) and make them explicit.

Note: some interaction with the Reproducible builds topic may be required.

Skills

  • Intermediate Embedded Linux knowledge (basic cross-compilation, advanced make...)

Follow upstream updates of packages

Mentor: Peter Korsgaard

Short: Provide infrastructure to easily follow version changes in upstream packages.

Support for LLVM

Mentor: Romain Naour

Short: Add support for building an LLVM/Clang-based cross-toolchain, and ensure as many packages as possible still build and run.

Upstream python patches

Mentor: Thomas Petazzoni

Short: Upstream our many and complex patches against Python (2 and 3) to support cross-compilation.

Support new languages

Mentor: Arnout Vandecapelle

Short: Add support for new languages (Go, Rust...).


Suggestions for candidates

If you want to apply, we recommend you to prove that you have some basic knowledge about Buildroot and open-source contributions:

  • Subscribe to the mailing list and come to the IRC channel
  • Post some patches to the mailing list. Here are some possible contribution ideas:
    • Look at some items in our TODO list at http://elinux.org/Buildroot#Todo_list, implement some of them, and send patches
    • Find some software component that is useful on embedded systems, create a Buildroot package for it, and send patches
    • Find some embedded hardware platform, create a Buildroot defconfig for it, and send patches
    • Look at some build failures in our autobuilders at http://autobuild.buildroot.org and send patches to fix them. Note that some build failures may be difficult to solve.
    • Look at the bug tracker at http://bugs.busybox.net and send patches to fix them. Some patches may be difficult to look at.