Testing changes before submitting a new PR

Testing your changes

Make sure that you tested your changes on various setups before opening a new PR. Try several different configuration options (in particular multiple architectures and platforms) and library combinations.

During development, disable CONFIG_OPTIMIZE_DEADELIM (Found in themenuconfig via “Build Options” -> “Drop unused functions and data”, or via kraft with kraft configure --no OPTIMIZE_DEADELIM) so that all of your code is covered by the compiler and linker.

Using checkpatch.pl

To support you in checking your coding style, we provide a tailored version of the Linux kernel’s checkpatch.pl script in support/scripts/checkpatch.pl. You should run this from the root of the Unikraft repository because it contains a .checkpatch.conf file which disables some tests that we consider irrelevant for Unikraft.

Please run this script on all commits you are about to submit. To do this, create a patch file for each commit on your working branch by running git format-patch. For example, to create patch files for the last 5 commits:

$ git format-patch HEAD~5
$ ./support/scripts/checkpatch.pl ./000*

You can also run the checkpatch on one or multiple files before committing by using the -f option. Furthermore, some errors can be automatically solved by using the --fix-inplace option:

$ ./support/scripts/checkpatch.pl --no-tree -f --fix-inplace <path/to/the/file>

For example, if you have some changes in the lib/vfscore/vfs.h, you can check and fix potential coding style issue with:

$ ./support/scripts/checkpatch.pl --no-tree --fix-inplace -f lib/vfscore/vfs.h
ERROR: "foo*bar" should be "foo *bar"
#576: FILE: lib/vfscore/vfs.h:576:
+int	sys_chmod(const char*path, mode_t mode);

total: 1 errors, 0 warnings, 828 lines checked

$ ./support/scripts/checkpatch.pl --no-tree --fix-inplace -f lib/vfscore/vfs.h
total: 0 errors, 0 warnings, 828 lines checked

lib/vfscore/vfs.h has no obvious style problems and is ready for submission.

Please attempt fixes for all errors and warnings; if you decide to ignore some, be prepared to have a good reason for each warning and error during the review process.