1 files changed, 89 insertions, 0 deletions
diff --git a/poky/documentation/dev-manual/init-manager.rst b/poky/documentation/dev-manual/init-manager.rst
new file mode 100644
index 0000000000..0617fed516
--- /dev/null
+++ b/poky/documentation/dev-manual/init-manager.rst
@@ -0,0 +1,89 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Selecting an Initialization Manager
+***********************************
+
+By default, the Yocto Project uses SysVinit as the initialization
+manager. However, there is also support for systemd, which is a full
+replacement for init with parallel starting of services, reduced shell
+overhead and other features that are used by many distributions.
+
+Within the system, SysVinit treats system components as services. These
+services are maintained as shell scripts stored in the ``/etc/init.d/``
+directory. Services organize into different run levels. This
+organization is maintained by putting links to the services in the
+``/etc/rcN.d/`` directories, where `N/` is one of the following options:
+"S", "0", "1", "2", "3", "4", "5", or "6".
+
+.. note::
+
+   Each runlevel has a dependency on the previous runlevel. This
+   dependency allows the services to work properly.
+
+In comparison, systemd treats components as units. Using units is a
+broader concept as compared to using a service. A unit includes several
+different types of entities. Service is one of the types of entities.
+The runlevel concept in SysVinit corresponds to the concept of a target
+in systemd, where target is also a type of supported unit.
+
+In a SysVinit-based system, services load sequentially (i.e. one by one)
+during init and parallelization is not supported. With systemd, services
+start in parallel. Needless to say, the method can have an impact on
+system startup performance.
+
+If you want to use SysVinit, you do not have to do anything. But, if you
+want to use systemd, you must take some steps as described in the
+following sections.
+
+Using systemd Exclusively
+=========================
+
+Set these variables in your distribution configuration file as follows::
+
+   DISTRO_FEATURES:append = " systemd"
+   VIRTUAL-RUNTIME_init_manager = "systemd"
+
+You can also prevent the SysVinit distribution feature from
+being automatically enabled as follows::
+
+   DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
+
+Doing so removes any
+redundant SysVinit scripts.
+
+To remove initscripts from your image altogether, set this variable
+also::
+
+   VIRTUAL-RUNTIME_initscripts = ""
+
+For information on the backfill variable, see
+:term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`.
+
+Using systemd for the Main Image and Using SysVinit for the Rescue Image
+========================================================================
+
+Set these variables in your distribution configuration file as follows::
+
+   DISTRO_FEATURES:append = " systemd"
+   VIRTUAL-RUNTIME_init_manager = "systemd"
+
+Doing so causes your main image to use the
+``packagegroup-core-boot.bb`` recipe and systemd. The rescue/minimal
+image cannot use this package group. However, it can install SysVinit
+and the appropriate packages will have support for both systemd and
+SysVinit.
+
+Using systemd-journald without a traditional syslog daemon
+==========================================================
+
+Counter-intuitively, ``systemd-journald`` is not a syslog runtime or provider,
+and the proper way to use systemd-journald as your sole logging mechanism is to
+effectively disable syslog entirely by setting these variables in your distribution
+configuration file::
+
+   VIRTUAL-RUNTIME_syslog = ""
+   VIRTUAL-RUNTIME_base-utils-syslog = ""
+
+Doing so will prevent ``rsyslog`` / ``busybox-syslog`` from being pulled in by
+default, leaving only ``journald``.
+