|
|
| Line 1: |
Line 1: |
| − | {{Stub}}
| + | * [[Kernel patches]] |
| − | | + | * [[Userspace patches]] |
| − | | |
| − | == Setting up working environment ==
| |
| − | | |
| − | === Obtaining the source code ===
| |
| − | | |
| − | The sources of OpenVZ components are tracked by Git SCM and placed on [[OpenVZ infrastructure|repositories]].
| |
| − | You either could download packed sources or use git tool itself.
| |
| − | | |
| − | For example to clone vzctl one need to type
| |
| − | | |
| − | git clone git://git.openvz.org/vzctl.git
| |
| − | | |
| − | | |
| − | === Compiling the source code ===
| |
| − | | |
| − | {{FIXME|describe how to compile OpenVZ components}}
| |
| − | | |
| − | | |
| − | == Changing the source code ==
| |
| − | | |
| − | === Kernel ===
| |
| − | | |
| − | When you change the source code keep in mind - we prefer tabs and indentations
| |
| − | to be 8 characters width. Consider reading [https://www.kernel.org/doc/Documentation/CodingStyle Linux kernel coding style].
| |
| − | | |
| − | Other "rules" could be learned from the source code - just make your code
| |
| − | to look similar.
| |
| − | | |
| − | === Userspace ===
| |
| − | | |
| − | {{FIXME|describe code style}}
| |
| − | | |
| − | | |
| − | == Producing a patch ==
| |
| − | | |
| − | === Kernel ===
| |
| − | | |
| − | There are at least two ways to make it right.
| |
| − | | |
| − | 1) git format-patch
| |
| − | | |
| − | You might need to read documentation on Git SCM how to prepare patch
| |
| − | 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"
| |
| − | | |
| − | Use <code>diff -up</code> or <code>diff -uprN</code> to create patches.
| |
| − | | |
| − | | |
| − | === Userspace ===
| |
| − | | |
| − | {{FIXME|describe preparing patch}}
| |
| − | | |
| − | | |
| − | == Checking patches for errors ==
| |
| − | | |
| − | === Kernel ===
| |
| − | | |
| − | 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).
| |
| − | | |
| − | | |
| − | === Userspace ===
| |
| − | | |
| − | Several of our components contains tests. To check whether your patches don't harm anything run:
| |
| − | | |
| − | make test
| |
| − | | |
| − | It will launch tests. Check for error messages produced by it.
| |
| − | Beside to functional and unit tests it would be good to check new code with [[Static code analysis|static
| |
| − | analysis tools]].
| |
| − | | |
| − | == Sending patches ==
| |
| − | | |
| − | === Kernel ===
| |
| − | | |
| − | Patches related to kernel should be sent to development mailing list devel@openvz.org
| |
| − | which is located at https://openvz.org/mailman/listinfo/devel. Pay attention that mails
| |
| − | from emails not subscribed to list must pass moderation (i.e. not so fast).
| |
| − | | |
| − | Please make sure the email client you're using doesn't screw your patch
| |
| − | (line wrapping and so on).
| |
| − | | |
| − | === Userspace ===
| |
| − | | |
| − | Patches related to userspace tools should be submitted to code review system (FIXME).
| |
| − | | |
| | | | |
| | == Wait for response == | | == Wait for response == |
