diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.xml b/poky/documentation/dev-manual/dev-manual-common-tasks.xml
index f72f81f..00741ee 100644
--- a/poky/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/poky/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -2349,7 +2349,7 @@
                 Most software provides some means of setting build-time
                 configuration options before compilation.
                 Typically, setting these options is accomplished by running a
-                configure script with some options, or by modifying a build
+                configure script with options, or by modifying a build
                 configuration file.
                 <note>
                     As of Yocto Project Release 1.7, some of the core recipes
@@ -2389,6 +2389,7 @@
                         software is built using Autotools.
                         If this is the case, you just need to worry about
                         modifying the configuration.</para>
+
                         <para>When using Autotools, your recipe needs to inherit
                         the
                         <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-autotools'><filename>autotools</filename></ulink>
@@ -2401,13 +2402,15 @@
                         or
                         <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS'><filename>PACKAGECONFIG_CONFARGS</filename></ulink>
                         to pass any needed configure options that are specific
-                        to the recipe.</para></listitem>
+                        to the recipe.
+                        </para></listitem>
                     <listitem><para><emphasis>CMake:</emphasis>
                         If your source files have a
                         <filename>CMakeLists.txt</filename> file, then your
                         software is built using CMake.
                         If this is the case, you just need to worry about
                         modifying the configuration.</para>
+
                         <para>When you use CMake, your recipe needs to inherit
                         the
                         <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-cmake'><filename>cmake</filename></ulink>
@@ -2417,7 +2420,16 @@
                         You can make some adjustments by setting
                         <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_OECMAKE'><filename>EXTRA_OECMAKE</filename></ulink>
                         to pass any needed configure options that are specific
-                        to the recipe.</para></listitem>
+                        to the recipe.
+                        <note>
+                            If you need to install one or more custom CMake
+                            toolchain files that are supplied by the
+                            application you are building, install the files to
+                            <filename>${D}${datadir}/cmake/</filename> Modules
+                            during
+                            <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>.
+                        </note>
+                        </para></listitem>
                     <listitem><para><emphasis>Other:</emphasis>
                         If your source files do not have a
                         <filename>configure.ac</filename> or
@@ -2780,6 +2792,14 @@
                         <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKEINST'><filename>PARALLEL_MAKEINST</filename></ulink>
                         for additional information.
                         </para></listitem>
+                    <listitem><para>
+                        If you need to install one or more custom CMake
+                        toolchain files that are supplied by the
+                        application you are building, install the files to
+                        <filename>${D}${datadir}/cmake/</filename> Modules
+                        during
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>.
+                        </para></listitem>
                 </itemizedlist>
             </note>
         </section>
@@ -5420,12 +5440,16 @@
                             <literallayout class='monospaced'>
      BBMULTICONFIG = "x86 arm"
                             </literallayout>
-                          </para>
-
-                          <para>Please note, that a "default" configuration already exists by definition,
-                          this configuration is named: "" (empty string) and is defined by the variables
-                          coming from your local.conf file. So, the previous example actually adds two
-                          additional configurations to your build "arm" and "x86" along with "".
+                            <note>
+                                A "default" configuration already exists by
+                                definition.
+                                This configuration is named: "" (i.e. empty
+                                string) and is defined by the variables coming
+                                from your <filename>local.conf</filename> file.
+                                Consequently, the previous example actually
+                                adds two additional configurations to your
+                                build: "arm" and "x86" along with "".
+                            </note>
                             </para></listitem>
                         <listitem><para>
                             <emphasis>Launch BitBake</emphasis>:
@@ -5445,9 +5469,10 @@
                             <filename>x86.conf</filename> configuration file,
                             a <filename>core-image-sato</filename>
                             image that is configured through the
-                            <filename>arm.conf</filename> configuration file and a
-                            <filename>core-image-base</filename> that is configured
-                            through your <filename>local.conf</filename> configuration file.
+                            <filename>arm.conf</filename> configuration file
+                            and a <filename>core-image-base</filename> that is
+                            configured through your
+                            <filename>local.conf</filename> configuration file.
                             </para></listitem>
                     </itemizedlist>
                     <note>
@@ -10820,6 +10845,47 @@
         </para>
 
         <para>
+            By default, the Yocto Project uses SysVinit as the initialization
+            manager.
+            However, support also exists 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.
+        </para>
+
+        <para>
+            Within the system, SysVinit treats system components as services.
+            These services are maintained as shell scripts stored in the
+            <filename>/etc/init.d/</filename> directory.
+            Services organize into different run levels.
+            This organization is maintained by putting links to the services
+            in the <filename>/etc/rcN.d/</filename> directories, where
+            <replaceable>N/</replaceable> 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.
+            </note>
+        </para>
+
+        <para>
+            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.
+        </para>
+
+        <para>
+            In a SysVinit-based system, services load sequentially (i.e. one
+            by one) during and parallelization is not supported.
+            With systemd, services start in parallel.
+            Needless to say, the method can have an impact on system startup
+            performance.
+        </para>
+
+        <para>
             If you want to use SysVinit, you do
             not have to do anything.
             But, if you want to use systemd, you must