| Line 1: |
Line 1: |
| − | == Setting up working enviroment == | + | == Set up working environment == |
| − | Although criu could be run as non-root(see [[Security]]), development is better to be done as root. For example, some tests require root. So, it would be a good idea to set up some recent Linux distro on a virtual machine.
| |
| | | | |
| − | === Obtaining the source code ===
| + | Although criu could be run as non-root (see [[Security]]), development is better to be done as root. For example, some tests require root. So, it would be a good idea to set up some recent Linux distro on a virtual machine. |
| | | | |
| − | The CRIU sources are tracked by Git SCM at [https://github.com/xemul/criu https://github.com/xemul/criu] repository. You either could download packed sources or use git
| + | == Get the source code == |
| − | tool itself.
| |
| | | | |
| − | For example to clone CRIU one need to type
| + | The CRIU sources are tracked by Git. Official CRIU repo is at [https://github.com/checkpoint-restore/criu https://github.com/checkpoint-restore/criu]. |
| | | | |
| − | git clone [https://github.com/xemul/criu https://github.com/xemul/criu]
| + | The repository may contain multiple branches. Development happens in the '''criu-dev''' branch. |
| | | | |
| − | === Compiling the source code ===
| + | To clone CRIU repo and switch to the proper branch, run: |
| | | | |
| − | {{Note|Dependencies are listed in the [[Installation]] article.}}
| + | <pre><nowiki> |
| − | Run:
| + | git clone https://github.com/checkpoint-restore/criu criu |
| | cd criu | | cd criu |
| | + | git checkout criu-dev |
| | + | </nowiki></pre> |
| | + | |
| | + | == Compile == |
| | + | |
| | + | First, you need to install compile-time dependencies. Check [[Installation#Dependencies]] for more info. |
| | + | |
| | + | To compile CRIU, run: |
| | + | |
| | make | | make |
| − | This will produce ./criu executable. | + | |
| − | As you are going to work with sources, it would come in handy to get tags by running:
| + | This should create the <code>./criu/criu</code> executable. |
| | + | |
| | + | == Edit the source code == |
| | + | |
| | + | If you use ctags, you can generate the ctags file by running |
| | + | |
| | make tags | | make tags |
| − | {{Note|It requires ctags to be installed.}}
| |
| | | | |
| − | == Changing the source code ==
| + | When you change the source code, please keep in mind the following code conventions: |
| | | | |
| − | When you change the source code keep in mind - we prefer tabs and
| + | * we prefer tabs and indentations to be 8 characters width |
| − | indentations to be 8 characters width. Consider reading [https://www.kernel.org/doc/Documentation/CodingStyle Linux kernel coding style]. | + | * CRIU mostly follows [https://www.kernel.org/doc/Documentation/process/coding-style.rst Linux kernel coding style], but we are less strict than the kernel community. |
| | | | |
| − | Other "rules" could be learned from the source code - just make your code | + | Other conventions can be learned from the source code itself. In short, make sure your new code |
| − | to look similar. | + | looks similar to what is already there. |
| | | | |
| − | == Producing a patch == | + | == Test your changes == |
| | | | |
| − | There are at least two ways to make it right.
| + | CRIU comes with an extensive test suite. To check whether your changes introduce any regressions, run |
| | | | |
| − | 1) git format-patch
| + | make test |
| | | | |
| − | You might need to read documentation on Git SCM how to prepare patch
| + | The command runs [[ZDTM Test Suite]]. Check for any error messages produced by it. |
| − | for mail submission. Take a look on http://book.git-scm.com/ and/or
| |
| − | http://git-scm.com/documentation for details. It should not be hard
| |
| − | at all.
| |
| | | | |
| − | 2) Use "diff -up"
| + | In case you'd rather have someone else run the tests, you can use travis-ci for your |
| | + | own github fork of CRIU. It will check the compilation for various supported platforms, |
| | + | as well as run most of the tests from the suite. See https://travis-ci.org/checkpoint-restore/criu |
| | + | for more details. |
| | | | |
| − | Use <code>diff -up</code> or <code>diff -uprN</code> to create patches.
| + | == Sign your work == |
| | | | |
| − | == Signing your work ==
| + | To improve tracking of who did what, we ask you to sign off the patches |
| − | | + | that are to be emailed. |
| − | To improve tracking of who did what we've introduced a "sign-off" procedure | |
| − | on patches that are being emailed around.
| |
| | | | |
| | The sign-off is a simple line at the end of the explanation for the | | The sign-off is a simple line at the end of the explanation for the |
| | patch, which certifies that you wrote it or otherwise have the right to | | patch, which certifies that you wrote it or otherwise have the right to |
| − | pass it on as a open-source patch. The rules are pretty simple: if you | + | pass it on as an open-source patch. The rules are pretty simple: if you |
| | can certify the below: | | can certify the below: |
| | | | |
| − | Developer's Certificate of Origin 1.1
| + | <div class="toccolours mw-collapsible mw-collapsed" style="width: 46em;"> |
| − |
| + | '''Developer's Certificate of Origin 1.1''' |
| | + | <div class="mw-collapsible-content"> |
| | By making a contribution to this project, I certify that: | | By making a contribution to this project, I certify that: |
| | | | |
| Line 80: |
Line 90: |
| | maintained indefinitely and may be redistributed consistent with | | maintained indefinitely and may be redistributed consistent with |
| | this project or the open source license(s) involved. | | this project or the open source license(s) involved. |
| − | | + | </div></div> |
| | then you just add a line saying | | then you just add a line saying |
| | | | |
| Line 92: |
Line 102: |
| | <code>git commit --amend -s</code>. | | <code>git commit --amend -s</code>. |
| | | | |
| − | == An example of patch message == | + | <div class="toccolours mw-collapsible mw-collapsed" style="width: 46em;"> |
| | + | '''Example patch message''' |
| | + | <div class="mw-collapsible-content"> |
| | | | |
| | From: Random J Developer <random at developer.example.org> | | From: Random J Developer <random at developer.example.org> |
| Line 103: |
Line 115: |
| | --- | | --- |
| | Patch body here | | Patch body here |
| | + | </div></div> |
| | | | |
| − | == Checking patches for errors == | + | == Submit your work upstream == |
| − | Basic style error checking is provided by scripts/checkpatch.pl script
| |
| − | from linux kernel source tree. You might have headers or complete sources
| |
| − | of linux kernel at /usr/src/. Run
| |
| − | checkpatch.pl my_patch.patch (consider --no-tree option for headers-only)
| |
| − | It will produce detailed report on style problems in your patch.
| |
| − | Make sure to fix all _errors_(some warnings may be ignored).
| |
| | | | |
| − | To check whether your patches don't harm anything run
| + | We accept github pull requests and this is the preferred way to contribute to CRIU. |
| − | make test
| + | For that you should push your work to your fork of CRIU at [https://github.com GitHub] and create a [https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests pull request] |
| − | It will launch [[ZDTM_Test_Suite]]. Check for error messages produced by it. | + | |
| − | You may also want to run other tests(rpc, libcriu, security etc) from test/ dir.
| + | Historically, CRIU worked with mailing lists and patches so if you still prefer this way continue reading till the end of this section. |
| | + | |
| | + | === Make a patch === |
| | + | |
| | + | To create a patch, run |
| | + | |
| | + | git format-patch --signoff origin/criu-dev |
| | + | |
| | + | You might need to read GIT documentation on how to prepare patches |
| | + | for mail submission. Take a look at http://book.git-scm.com/ and/or |
| | + | http://git-scm.com/documentation for details. It should not be hard |
| | + | at all. |
| | + | |
| | + | We recommend to post patches using <code>git send-email</code> |
| | + | |
| | + | git send-email --cover-letter --no-chain-reply-to --annotate \ |
| | + | --confirm=always --to=criu@openvz.org criu-dev |
| | + | |
| | + | Note that the <code>git send-email</code> subcommand may not be in |
| | + | the main git package and using it may require installation of a |
| | + | separate package, for example the "git-email" package in Fedora and |
| | + | Debian. |
| | + | |
| | + | If this is your first time using git send-email, you might need to |
| | + | configure it to point it to your SMTP server with something like: |
| | + | |
| | + | git config --global sendemail.smtpServer stmp.example.net |
| | + | |
| | + | If you get tired of typing <code>--to=criu@openvz.org</code> all the time, |
| | + | you can configure that to be automatically handled as well: |
| | + | |
| | + | git config sendemail.to criu@openvz.org |
| | + | |
| | + | If a developer is sending another version of the patch (e.g. to address |
| | + | review comments), they are advised to note differences to previous versions |
| | + | after the <code>---</code> line in the patch so that it helps reviewers but |
| | + | doesn't become part of git history. Moreover, such patch needs to be prefixed |
| | + | correctly with <code>--subject-prefix=PATCHv2</code> appended to |
| | + | <code>git send-email</code> (substitute <code>v2</code> with the correct |
| | + | version if needed though). |
| | + | |
| | + | === Mail patches === |
| | | | |
| − | == Mailing patches ==
| + | The patches should be sent to CRIU development mailing list, <code>criu AT openvz.org</code>. Note that you need to be subscribed first in order to post. The list web interface is available at https://openvz.org/mailman/listinfo/criu; you can also use standard mailman aliases to work with it. |
| | | | |
| − | The patches should be sent to CRIU development mailing list
| + | Please make sure the email client you're using doesn't screw your patch (line wrapping and so on). |
| − | which is located at https://openvz.org/mailman/listinfo/criu
| |
| | | | |
| − | Please make sure the email client you're using doesn't screw
| + | {{Note| When sending a patch set that consists of more than one patch, please, push your changes in your local repo and provide the URL of the branch in the cover-letter}} |
| − | your patch (line wrapping and so on). | |
| | | | |
| − | == Wait for response == | + | === Wait for response === |
| | | | |
| | Be patient. Most CRIU developers are pretty busy people so if | | Be patient. Most CRIU developers are pretty busy people so if |
| − | there is no immediate response on your patch - don't be surprised, | + | there is no immediate response on your patch — don't be surprised, |
| − | sometimes a patch may fly around a week(s) before it get reviewed. | + | sometimes a patch may fly around a week before it gets reviewed. |
| − | But definitely the patches will not go to <code>/dev/null</code>.
| + | |
| | + | == Continuous integration == |
| | + | |
| | + | ''Main article: [[Continuous integration]]'' |
| | + | |
| | + | CRIU tests are run for each series sent to the mailing list. If you get a message from our patchwork that patches failed to pass the tests, you have to investigate what is wrong. |
| | + | |
| | + | We also recommend you to [[Continuous integration#Enable Travis CI for your repo|enable Travis CI for your repo]] to check patches in your git branch, before sending them to the mailing list. |
| | | | |
| | [[Category:Development]] | | [[Category:Development]] |