Draft Roadmap

Documentation

The documentation is available directly on github.

Here is the main documentation to build a SEAPATH image: https://github.com/seapath/yocto-bsp/blob/master/README.adoc

Build machine

The Yocto project requires a powerful Linux based machine.

In order to build efficiently the SEAPATH project, we recommend not to use Virtual Machine. The Yocto project will ensure to multi-thread your build, so try to use a build machine with many CPU cores.

Here is a discussion on the Yocto Project mailing list: https://lists.yoctoproject.org/g/yocto/topic/72047879#48815

Here is for instance, a build configuration (~1500 euros) used:

Tips for building

• About 250GB is needed for building SEAPATH.
• A USB attached storage may be too slow to be practical for a successful build.
• Ensure you use an ext 2/ ext3 / ext4 filesystem for the build directory. NTFS will not work.
• Watch out with only manually deleting the /tmp/work directory. Instead delete the whole tmp directory.
• When deleting the tmp, it may take a very long time, and might cause rm -rf to fail with an error. find . -delete will work better, as it will not try to index all files before deleting them.

Test Bench hardware

Specification

Tests results

Real time

With the previous test bench hardware, a couple of tests were used.

We used ```cyclictest```.

"Cyclictest accurately and repeatedly measures the difference between a thread's intended wake-up time and the time at which it actually wakes up in order to provide statistics about the system's latencies. It can measure latencies in real-time systems caused by the hardware, the firmware, and the operating system." (source: https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start)

The following arguments were provided:

cyclictest -l100000000 -m -Sp90 -i200 -h400 -q >output

Contribution process

• Create a personal fork of the project on Github
• Clone the fork on your local machine
• Make sure to pull upstream changes into your local repository
• Implement/fix your feature, comment your code if needed
• Follow the code style of the project, including indentation
• Run tests on the hardware you want to install the distribution and ensure that no regression are seen (ex: cukinia)
• Provide the hardware specification
• Write or adapt tests as needed
• Add or change the documentation as needed.
• Squash intermediary commits (fixes, WIP, …) with git's interactive rebase. 
• Make sure to split your commit
• Each commit should only add one feature
• Use two separate commits when adding a package and enabling it
• Make sure that your commit message is consistent with the git history
• Prefix the commit title by the area touch 
• ex: images/seapath-host-common.inc: add STONITH plugins
• Separate subject from body with a blank line
• Limit the subject line to 50 characters
• Use the imperative mood in the subject line
• Wrap the body at 72 characters
• Use the body to explain what and why vs. how

More details can be found there.

• Sign off your commit

• Push your branch to your fork on Github
• From your fork open a pull request