man: make Notes section in systemd.geneator(5) toplevel

This is mostly a indentation change and rewrapping.

1 files changed, 120 insertions, 147 deletions

diff --git a/man/systemd.generator.xml b/man/systemd.generator.xml
index a41e43df0f..60ca0cecad 100644
--- a/man/systemd.generator.xml
+++ b/man/systemd.generator.xml
@@ -170,135 +170,112 @@
         the vendor or user/administrator take precedence.</para>
       </listitem>
     </orderedlist>
+  </refsect1>
+
+  <refsect1>
+    <title>Notes about writing generators</title>
+
+    <itemizedlist>
+      <listitem>
+        <para>All generators are executed in parallel. That means all executables are
+        started at the very same time and need to be able to cope with this
+        parallelism.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>Generators are run very early at boot and cannot rely on any external
+        services. They may not talk to any other process. That includes simple things
+        such as logging to
+        <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
+        or <command>systemd</command> itself (this means: no
+        <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>)!
+        Non-essential file systems like <filename>/var</filename> and
+        <filename>/home</filename> are mounted after generators have run. Generators
+        can however rely on the most basic kernel functionality to be available,
+        including a mounted <filename>/sys</filename>, <filename>/proc</filename>,
+        <filename>/dev</filename>, <filename>/usr</filename>.
+        </para>
+      </listitem>
+
+      <listitem>
+        <para>Units written by generators are removed when the configuration is
+        reloaded. That means the lifetime of the generated units is closely bound to
+        the reload cycles of <command>systemd</command> itself.</para>
+      </listitem>
+
+      <listitem>
+        <para>Generators should only be used to generate unit files and symlinks to
+        them, not any other kind of configuration. Due to the lifecycle logic
+        mentioned above, generators are not a good fit to generate dynamic
+        configuration for other services. If you need to generate dynamic
+        configuration for other services, do so in normal services you order before
+        the service in question.</para>
+      </listitem>
 
-    <refsect2>
-      <title>Notes</title>
-
-      <itemizedlist>
-        <listitem>
-          <para>
-            All generators are executed in parallel. That means all
-            executables are started at the very same time and need to
-            be able to cope with this parallelism.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Generators are run very early at boot and cannot rely on
-            any external services. They may not talk to any other
-            process. That includes simple things such as logging to
-            <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
-            or <command>systemd</command> itself (this means: no
-            <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>)!
-            Non-essential file systems like
-            <filename>/var</filename> and <filename>/home</filename>
-            are mounted after generators have run. Generators
-            can however rely on the most basic kernel functionality to be
-            available, including a mounted <filename>/sys</filename>,
-            <filename>/proc</filename>, <filename>/dev</filename>,
-            <filename>/usr</filename>.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Units written by generators are removed when the configuration
-            is reloaded. That means the lifetime of the generated
-            units is closely bound to the reload cycles of
-            <command>systemd</command> itself.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Generators should only be used to generate unit files and symlinks to them, not any other kind of
-            configuration. Due to the lifecycle logic mentioned above, generators are not a good fit to generate
-            dynamic configuration for other services. If you need to generate dynamic configuration for other services,
-            do so in normal services you order before the service in question.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Since
-            <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
-            is not available (see above), log messages have to be
-            written to <filename>/dev/kmsg</filename> instead.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            It is a good idea to use the
-            <varname>SourcePath=</varname> directive in generated unit
-            files to specify the source configuration file you are
-            generating the unit from. This makes things more easily
-            understood by the user and also has the benefit that
-            systemd can warn the user about configuration files that
-            changed on disk but have not been read yet by systemd.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Generators may write out dynamic unit files or just hook
-            unit files into other units with the usual
-            <filename>.wants/</filename> or
-            <filename>.requires/</filename> symlinks. Often, it is
-            nicer to simply instantiate a template unit file from
-            <filename>/usr</filename> with a generator instead of
-            writing out entirely dynamic unit files. Of course, this
-            works only if a single parameter is to be used.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            If you are careful, you can implement generators in shell
-            scripts. We do recommend C code however, since generators
-            are executed synchronously and hence delay the
-            entire boot if they are slow.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>Regarding overriding semantics: there are two rules we
-          try to follow when thinking about the overriding semantics:
-          </para>
-
-          <orderedlist numeration="lowerroman">
-            <listitem>
-              <para>User configuration should override vendor
-              configuration. This (mostly) means that stuff from
-              <filename>/etc</filename> should override stuff from
-              <filename>/usr</filename>.</para>
-            </listitem>
-
-            <listitem>
-              <para>Native configuration should override non-native
-              configuration. This (mostly) means that stuff you
-              generate should never override native unit files for the
-              same purpose.</para>
-            </listitem>
-          </orderedlist>
-
-          <para>Of these two rules the first rule is probably the more
-          important one and breaks the second one sometimes. Hence,
-          when deciding whether to use argv[1], argv[2], or argv[3],
-          your default choice should probably be argv[1].</para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Instead of heading off now and writing all kind of
-            generators for legacy configuration file formats, please
-            think twice! It is often a better idea to just deprecate
-            old stuff instead of keeping it artificially alive.
-          </para>
-        </listitem>
-      </itemizedlist>
-    </refsect2>
+      <listitem>
+        <para>Since
+        <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
+
+        is not available (see above), log messages have to be written to
+        <filename>/dev/kmsg</filename> instead.</para>
+      </listitem>
+
+      <listitem>
+        <para>It is a good idea to use the <varname>SourcePath=</varname> directive
+        in generated unit files to specify the source configuration file you are
+        generating the unit from. This makes things more easily understood by the
+        user and also has the benefit that systemd can warn the user about
+        configuration files that changed on disk but have not been read yet by
+        systemd.</para>
+      </listitem>
+
+      <listitem>
+        <para>Generators may write out dynamic unit files or just hook unit files
+        into other units with the usual <filename>.wants/</filename> or
+        <filename>.requires/</filename> symlinks. Often, it is nicer to simply
+        instantiate a template unit file from <filename>/usr</filename> with a
+        generator instead of writing out entirely dynamic unit files. Of course, this
+        works only if a single parameter is to be used.</para>
+      </listitem>
+
+      <listitem>
+        <para>If you are careful, you can implement generators in shell scripts. We
+        do recommend C code however, since generators are executed synchronously and
+        hence delay the entire boot if they are slow.</para>
+      </listitem>
+
+      <listitem>
+        <para>Regarding overriding semantics: there are two rules we try to follow
+        when thinking about the overriding semantics:</para>
+
+        <orderedlist numeration="lowerroman">
+          <listitem>
+            <para>User configuration should override vendor configuration. This
+            (mostly) means that stuff from <filename>/etc</filename> should override
+            stuff from <filename>/usr</filename>.</para>
+          </listitem>
+
+          <listitem>
+            <para>Native configuration should override non-native configuration. This
+            (mostly) means that stuff you generate should never override native unit
+            files for the same purpose.</para>
+          </listitem>
+        </orderedlist>
+
+        <para>Of these two rules the first rule is probably the more important one
+        and breaks the second one sometimes. Hence, when deciding whether to use
+        argv[1], argv[2], or argv[3], your default choice should probably be
+        argv[1].</para>
+      </listitem>
+
+      <listitem>
+        <para>Instead of heading off now and writing all kind of generators for
+        legacy configuration file formats, please think twice! It is often a better
+        idea to just deprecate old stuff instead of keeping it artificially alive.
+        </para>
+      </listitem>
+    </itemizedlist>
   </refsect1>
 
   <refsect1>
@@ -307,22 +284,18 @@
       <title>systemd-fstab-generator</title>
 
       <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
-      converts <filename>/etc/fstab</filename> into native mount
-      units. It uses argv[1] as location to place the generated unit
-      files in order to allow the user to override
-      <filename>/etc/fstab</filename> with her own native unit files,
-      but also to ensure that <filename>/etc/fstab</filename>
-      overrides any vendor default from <filename>/usr</filename>.
-      </para>
-
-      <para>After editing <filename>/etc/fstab</filename>, the user
-      should invoke <command>systemctl daemon-reload</command>. This
-      will re-run all generators and cause <command>systemd</command>
-      to reload units from disk. To actually mount new directories
-      added to <filename>fstab</filename>, <command>systemctl start
-      <replaceable>/path/to/mountpoint</replaceable></command> or
-      <command>systemctl start local-fs.target</command> may be used.
-      </para>
+      converts <filename>/etc/fstab</filename> into native mount units. It uses
+      argv[1] as location to place the generated unit files in order to allow the
+      user to override <filename>/etc/fstab</filename> with her own native unit
+      files, but also to ensure that <filename>/etc/fstab</filename> overrides any
+      vendor default from <filename>/usr</filename>.</para>
+
+      <para>After editing <filename>/etc/fstab</filename>, the user should invoke
+      <command>systemctl daemon-reload</command>. This will re-run all generators and
+      cause <command>systemd</command> to reload units from disk. To actually mount
+      new directories added to <filename>fstab</filename>, <command>systemctl start
+      <replaceable>/path/to/mountpoint</replaceable></command> or <command>systemctl
+      start local-fs.target</command> may be used.</para>
     </example>
 
     <example>
@@ -331,9 +304,9 @@
       <para><citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
       temporarily redirects <filename>default.target</filename> to
       <filename>system-update.target</filename>, if a system update is
-      scheduled. Since this needs to override the default user
-      configuration for <filename>default.target</filename>, it uses
-      argv[2]. For details about this logic, see
+      scheduled. Since this needs to override the default user configuration for
+      <filename>default.target</filename>, it uses argv[2]. For details about this
+      logic, see
       <citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
       </para>
     </example>