Merge pull request #16697 from yuwata/network-fix-suspend-issue

[thirdparty/systemd.git] / docs / HACKING.md

diff --git a/docs/HACKING.md b/docs/HACKING.md
index 4a7d5680874dae31d0102804874ef423008aba2c..990f78c9eb43856f99ec161a135ca2e4fa0634aa 100644 (file)
--- a/docs/HACKING.md
+++ b/docs/HACKING.md
@@ -1,3 +1,9 @@
+---
+title: Hacking on systemd
+category: Contributing
+layout: default
+---
+
 # Hacking on systemd
 
 We welcome all contributions to systemd. If you notice a bug or a missing
@@ -13,7 +19,7 @@ policy is to keep tests in matching files underneath `src/test/`,
 e.g. `src/test/test-path-util.c` contains tests for any functions in
 `src/basic/path-util.c`. If adding a new source file, consider adding a matching
 test executable. For features at a higher level, tests in `src/test/` are very
-strongly recommended. If that is no possible, integration tests in `test/` are
+strongly recommended. If that is not possible, integration tests in `test/` are
 encouraged.
 
 Please also have a look at our list of [code quality tools](CODE_QUALITY.md) we have setup for systemd,
@@ -30,9 +36,12 @@ building clean OS images from an upstream distribution in combination with a
 fresh build of the project in the local working directory. To make use of this,
 please acquire `mkosi` from https://github.com/systemd/mkosi first, unless your
 distribution has packaged it already and you can get it from there. After the
-tool is installed it is sufficient to type `mkosi` in the systemd project
-directory to generate a disk image `image.raw` you can boot either in
-`systemd-nspawn` or in an UEFI-capable VM:
+tool is installed, symlink the settings file for your distribution of choice from
+.mkosi/ to mkosi.default in the project root directory (note that the package
+manager for this distro needs to be installed on your host system). After doing
+that, it is sufficient to type `mkosi` in the systemd project directory to
+generate a disk image `image.raw` you can boot either in `systemd-nspawn` or in
+an UEFI-capable VM:
 
 ```
 # systemd-nspawn -bi image.raw
@@ -66,22 +75,23 @@ Putting this all together, here's a series of commands for preparing a patch
 for systemd (this example is for Fedora):
 
 ```sh
-$ sudo dnf builddep systemd            # install build dependencies
-$ sudo dnf install mkosi               # install tool to quickly build images
+$ sudo dnf builddep systemd               # install build dependencies
+$ sudo dnf install mkosi                  # install tool to quickly build images
 $ git clone https://github.com/systemd/systemd.git
 $ cd systemd
-$ vim src/core/main.c                  # or wherever you'd like to make your changes
-$ meson build                          # configure the build
-$ ninja -C build                       # build it locally, see if everything compiles fine
-$ ninja -C build test                  # run some simple regression tests
-$ (umask 077; echo 123 > mkosi.rootpw) # set root password used by mkosi
-$ sudo mkosi                           # build a test image
-$ sudo systemd-nspawn -bi image.raw    # boot up the test image
-$ git add -p                           # interactively put together your patch
-$ git commit                           # commit it
+$ vim src/core/main.c                     # or wherever you'd like to make your changes
+$ meson build                             # configure the build
+$ ninja -C build                          # build it locally, see if everything compiles fine
+$ ninja -C build test                     # run some simple regression tests
+$ ln -s .mkosi/mkosi.fedora mkosi.default # Configure mkosi to build a fedora image
+$ (umask 077; echo 123 > mkosi.rootpw)    # set root password used by mkosi
+$ sudo mkosi                              # build a test image
+$ sudo systemd-nspawn -bi image.raw       # boot up the test image
+$ git add -p                              # interactively put together your patch
+$ git commit                              # commit it
 $ git push REMOTE HEAD:refs/heads/BRANCH
-                                       # where REMOTE is your "fork" on GitHub
-                                       # and BRANCH is a branch name.
+                                          # where REMOTE is your "fork" on GitHub
+                                          # and BRANCH is a branch name.
 ```
 
 And after that, head over to your repo on GitHub and click "Compare & pull request"
@@ -92,8 +102,8 @@ Happy hacking!
 ## Fuzzers
 
 systemd includes fuzzers in `src/fuzz/` that use libFuzzer and are automatically
-run by [OSS-Fuzz](https://github.com/google/oss-fuzz) with sanitizers. To add a
-fuzz target, create a new `src/fuzz/fuzz-foo.c` file with a `LLVMFuzzerTestOneInput`
+run by [OSS-Fuzz](https://github.com/google/oss-fuzz) with sanitizers.
+To add a fuzz target, create a new `src/fuzz/fuzz-foo.c` file with a `LLVMFuzzerTestOneInput`
 function and add it to the list in `src/fuzz/meson.build`.
 
 Whenever possible, a seed corpus and a dictionary should also be added with new
@@ -117,7 +127,5 @@ guidance in [CONTRIBUTING.md](CONTRIBUTING.md) on how to report a security vulne
 
 For more details on building fuzzers and integrating with OSS-Fuzz, visit:
 
-- https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md
-- https://llvm.org/docs/LibFuzzer.html
-- https://github.com/google/fuzzer-test-suite/blob/master/tutorial/libFuzzerTutorial.md
-- https://chromium.googlesource.com/chromium/src/testing/libfuzzer/+/HEAD/efficient_fuzzer.md
+- [Setting up a new project - OSS-Fuzz](https://google.github.io/oss-fuzz/getting-started/new-project-guide/)
+- [Tutorials - OSS-Fuzz](https://google.github.io/oss-fuzz/reference/useful-links/#tutorials)