man: update tags in systemd-stub(7)

- use <literal> for section name,
- use <command> for systemd-stub,
- drop '=' suffix from EFI variable name.

diff --git a/man/systemd-stub.xml b/man/systemd-stub.xml
index 09de149d42d76f627153b30eee8a60fc54606478..f81e67da30544c62b1b77c076f07160efbaedad6 100644 (file)
--- a/man/systemd-stub.xml
+++ b/man/systemd-stub.xml
@@ -81,27 +81,27 @@
       <listitem><para>An optional <literal>.dtb</literal> section with a compiled binary DeviceTree.
       </para></listitem>
 
-      <listitem><para>Zero or more <literal>.dtbauto</literal> sections. <filename>systemd-stub</filename>
+      <listitem><para>Zero or more <literal>.dtbauto</literal> sections. <command>systemd-stub</command>
       will always use the first matching one. The match is performed by taking the first DeviceTree's
-      <varname>compatible</varname> string supplied by the firmware in configuration tables and comparing it
-      with the first <varname>compatible</varname> string from each of the <literal>.dtbauto</literal>
+      <literal>compatible</literal> string supplied by the firmware in configuration tables and comparing it
+      with the first <literal>compatible</literal> string from each of the <literal>.dtbauto</literal>
       sections. If the firmware does not provide a DeviceTree, the match is done using the
-      <varname>.hwids</varname> section instead. After selecting a <literal>.hwids</literal> section (see the
-      description below), the <varname>compatible</varname> string from that section will be used to perform
+      <literal>.hwids</literal> section instead. After selecting a <literal>.hwids</literal> section (see the
+      description below), the <literal>compatible</literal> string from that section will be used to perform
       the same matching procedure. If a match is found, that <literal>.dtbauto</literal> section will be
-      loaded and will override <varname>.dtb</varname> if present.</para></listitem>
+      loaded and will override <literal>.dtb</literal> if present.</para></listitem>
 
       <listitem><para>Zero or more <literal>.efifw</literal> sections for the firmware image. It works
-      in many ways similar to <literal>.dtbauto</literal> sections. <filename>systemd-stub</filename>
+      in many ways similar to <literal>.dtbauto</literal> sections. <command>systemd-stub</command>
       will always use the first matching one. The match is performed by first selecting the most appropriate
-      entry in the <varname>.hwids</varname> section based on the hardware IDs supplied by SMBIOS (see below).
-      If a suitable entry is found, the <varname>fwid</varname> string from that entry will be used to
-      perform the matching procedure for firmware blobs in <varname>.efifw</varname> section. The first
+      entry in the <literal>.hwids</literal> section based on the hardware IDs supplied by SMBIOS (see below).
+      If a suitable entry is found, the <literal>fwid</literal> string from that entry will be used to
+      perform the matching procedure for firmware blobs in <literal>.efifw</literal> section. The first
       matching firmware will be loaded.
       </para></listitem>
 
       <listitem><para>Zero or more <literal>.hwids</literal> sections with hardware IDs of the machines to
-      match DeviceTrees. <filename>systemd-stub</filename> will use the SMBIOS data to calculate hardware IDs
+      match DeviceTrees. <command>systemd-stub</command> will use the SMBIOS data to calculate hardware IDs
       of the machine (as per <ulink
       url="https://learn.microsoft.com/en-us/windows-hardware/drivers/install/specifying-hardware-ids-for-a-computer">specification</ulink>),
       and then it will try to find any of them in each of the <literal>.hwids</literal> sections. The first
@@ -189,7 +189,7 @@
       archive is generated from all files found that way, placing them in the
       <filename>/.extra/credentials/</filename> directory of the initrd file hierarchy. The main initrd may
       then access them in this directory. This is supposed to be used to store auxiliary, encrypted,
-      authenticated credentials for use with <varname>LoadCredentialEncrypted=</varname> in the UEFI System
+      authenticated credentials for use with <varname>LoadCredentialEncrypted</varname> in the UEFI System
       Partition. See
       <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
       and