HACKING

   1 HACKING ON SYSTEMD
   2
   3 We welcome all contributions to systemd. If you notice a bug or a missing
   4 feature, please feel invited to fix it, and submit your work as a github Pull
   5 Request (PR):
   6
   7         https://github.com/systemd/systemd/pull/new
   8
   9 Please make sure to follow our Coding Style when submitting patches. See
  10 CODING_STYLE for details. Also have a look at our Contribution Guidelines:
  11
  12         https://github.com/systemd/systemd/blob/master/.github/CONTRIBUTING.md
  13
  14 Please always test your work before submitting a PR. For many of the components
  15 of systemd testing is straight-forward as you can simply compile systemd and
  16 run the relevant tool from the build directory.
  17
  18 For some components (most importantly, systemd/PID1 itself) this is not
  19 possible, however. In order to simplify testing for cases like this we provide
  20 a set of "mkosi" build files directly in the source tree. "mkosi" is a tool for
  21 building clean OS images from an upstream distribution in combination with a
  22 fresh build of the project in the local working directory. To make use of this,
  23 please acquire "mkosi" from https://github.com/systemd/mkosi first, unless your
  24 distribution has packaged it already and you can get it from there. After the
  25 tool is installed it is sufficient to type "mkosi" in the systemd project
  26 directory to generate a disk image "image.raw" you can boot either in
  27 systemd-nspawn or in an UEFI-capable VM:
  28
  29         # systemd-nspawn -bi image.raw
  30
  31 or:
  32
  33         # qemu-kvm -m 512 -smp 2 -bios /usr/share/edk2/ovmf/OVMF_CODE.fd -hda image.raw
  34
  35 Every time you rerun the "mkosi" command a fresh image is built, incorporating
  36 all current changes you made to the project tree.
  37
  38 Alternatively, you may install the systemd version from your git check-out
  39 directly on top of your host system's directory tree. This mostly works fine,
  40 but of course you should know what you are doing as you might make your system
  41 unbootable in case of a bug in your changes. Also, you might step into your
  42 package manager's territory with this. Be careful!
  43
  44 And never forget: most distributions provide very simple and convenient ways to
  45 install all development packages necessary to build systemd. For example, on
  46 Fedora the following command line should be sufficient to install all of
  47 systemd's build dependencies:
  48
  49         # dnf builddep systemd
  50
  51 Putting this all together, here's a series of commands for preparing a patch
  52 for systemd (this example is for Fedora):
  53
  54         $ sudo dnf builddep systemd            # install build dependencies
  55         $ sudo dnf install mkosi               # install tool to quickly build images
  56         $ git clone https://github.com/systemd/systemd.git
  57         $ cd systemd
  58         $ vim src/core/main.c                  # or wherever you'd like to make your changes
  59         $ ./autogen.sh c                       # configure the source tree
  60         $ make -j `nproc`                      # build it locally, see if everything compiles fine
  61         $ make -j `nproc` check                # run some simple regression tests
  62         $ sudo mkosi                           # build a test image
  63         $ sudo systemd-nspawn -bi image.raw    # boot up the test image
  64         $ git add -p                           # interactively put together your patch
  65         $ git commit                           # commit it
  66         $ ...
  67
  68 And after that, please submit your branch as PR to systemd via github.
  69
  70 Happy hacking!