docbook2man picks up some errors that docbook2x does not, fixing them
isn't harmful to docbook2x. The only real change is adding <para> and
<citerefentry> tags.

Signed-off-by: Dwight Engen <dwight.en...@oracle.com>
---
 doc/lxc.conf.sgml.in | 156 +++++++++++++++++++++++++++++----------------------
 1 file changed, 88 insertions(+), 68 deletions(-)

diff --git a/doc/lxc.conf.sgml.in b/doc/lxc.conf.sgml.in
index dd68d48..ac3e377 100644
--- a/doc/lxc.conf.sgml.in
+++ b/doc/lxc.conf.sgml.in
@@ -668,81 +668,101 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, 
Boston, MA 02110-1301 USA
            </para>
            <itemizedlist>
              <listitem>
-               <option>proc:mixed</option> (or <option>proc</option>):
-               mount <filename>/proc</filename> as read-write, but
-               remount <filename>/proc/sys</filename> and
-               <filename>/proc/sysrq-trigger</filename> read-only
-               for security / container isolation purposes.
+               <para>
+                 <option>proc:mixed</option> (or <option>proc</option>):
+                 mount <filename>/proc</filename> as read-write, but
+                 remount <filename>/proc/sys</filename> and
+                 <filename>/proc/sysrq-trigger</filename> read-only
+                 for security / container isolation purposes.
+               </para>
              </listitem>
              <listitem>
-               <option>proc:rw</option>: mount
-               <filename>/proc</filename> as read-write
+               <para>
+                 <option>proc:rw</option>: mount
+                 <filename>/proc</filename> as read-write
+               </para>
              </listitem>
              <listitem>
-               <option>sys:ro</option> (or <option>sys</option>):
-               mount <filename>/sys</filename> as read-only
-               for security / container isolation purposes.
+               <para>
+                 <option>sys:ro</option> (or <option>sys</option>):
+                 mount <filename>/sys</filename> as read-only
+                 for security / container isolation purposes.
+               </para>
              </listitem>
              <listitem>
-               <option>sys:rw</option>: mount
-               <filename>/sys</filename> as read-write
+               <para>
+                 <option>sys:rw</option>: mount
+                 <filename>/sys</filename> as read-write
+               </para>
              </listitem>
              <listitem>
-               <option>cgroup:mixed</option> (or
-               <option>cgroup</option>):
-               mount a tmpfs to <filename>/sys/fs/cgroup</filename>,
-               create directories for all hierarchies to which
-               the container is added, create subdirectories
-               there with the name of the cgroup, and bind-mount
-               the container's own cgroup into that directory.
-               The container will be able to write to its own
-               cgroup directory, but not the parents, since they
-               will be remounted read-only
+               <para>
+                 <option>cgroup:mixed</option> (or
+                 <option>cgroup</option>):
+                 mount a tmpfs to <filename>/sys/fs/cgroup</filename>,
+                 create directories for all hierarchies to which
+                 the container is added, create subdirectories
+                 there with the name of the cgroup, and bind-mount
+                 the container's own cgroup into that directory.
+                 The container will be able to write to its own
+                 cgroup directory, but not the parents, since they
+                 will be remounted read-only
+               </para>
              </listitem>
              <listitem>
-               <option>cgroup:ro</option>: similar to
-               <option>cgroup:mixed</option>, but everything will
+               <para>
+                 <option>cgroup:ro</option>: similar to
+                 <option>cgroup:mixed</option>, but everything will
                be mounted read-only.
+               </para>
              </listitem>
              <listitem>
-               <option>cgroup:rw</option>: similar to
-               <option>cgroup:mixed</option>, but everything will
-               be mounted read-write. Note that the paths leading
-               up to the container's own cgroup will be writable,
-               but will not be a cgroup filesystem but just part
-               of the tmpfs of <filename>/sys/fs/cgroup</filename>
+               <para>
+                 <option>cgroup:rw</option>: similar to
+                 <option>cgroup:mixed</option>, but everything will
+                 be mounted read-write. Note that the paths leading
+                 up to the container's own cgroup will be writable,
+                 but will not be a cgroup filesystem but just part
+                 of the tmpfs of <filename>/sys/fs/cgroup</filename>
+               </para>
              </listitem>
              <listitem>
-               <option>cgroup-full:mixed</option> (or
-               <option>cgroup-full</option>):
-               mount a tmpfs to <filename>/sys/fs/cgroup</filename>,
-               create directories for all hierarchies to which
-               the container is added, bind-mount the hierarchies
-               from the host to the container and make everything
-               read-only except the container's own cgroup. Note
-               that compared to <option>cgroup</option>, where
-               all paths leading up to the container's own cgroup
-               are just simple directories in the underlying
-               tmpfs, here
-               <filename>/sys/fs/cgroup/$hierarchy</filename>
-               will contain the host's full cgroup hierarchy,
-               albeit read-only outside the container's own cgroup.
-               This may leak quite a bit of information into the
-               container.
+               <para>
+                 <option>cgroup-full:mixed</option> (or
+                 <option>cgroup-full</option>):
+                 mount a tmpfs to <filename>/sys/fs/cgroup</filename>,
+                 create directories for all hierarchies to which
+                 the container is added, bind-mount the hierarchies
+                 from the host to the container and make everything
+                 read-only except the container's own cgroup. Note
+                 that compared to <option>cgroup</option>, where
+                 all paths leading up to the container's own cgroup
+                 are just simple directories in the underlying
+                 tmpfs, here
+                 <filename>/sys/fs/cgroup/$hierarchy</filename>
+                 will contain the host's full cgroup hierarchy,
+                 albeit read-only outside the container's own cgroup.
+                 This may leak quite a bit of information into the
+                 container.
+               </para>
              </listitem>
              <listitem>
-               <option>cgroup-full:ro</option>: similar to
-               <option>cgroup-full:mixed</option>, but everything
-               will be mounted read-only.
+               <para>
+                 <option>cgroup-full:ro</option>: similar to
+                 <option>cgroup-full:mixed</option>, but everything
+                 will be mounted read-only.
+               </para>
              </listitem>
              <listitem>
-               <option>cgroup-full:rw</option>: similar to
-               <option>cgroup-full:mixed</option>, but everything
-               will be mounted read-write. Note that in this case,
-               the container may escape its own cgroup. (Note also
-               that if the container has CAP_SYS_ADMIN support
-               and can mount the cgroup filesystem itself, it may
-               do so anyway.)
+               <para>
+                 <option>cgroup-full:rw</option>: similar to
+                 <option>cgroup-full:mixed</option>, but everything
+                 will be mounted read-write. Note that in this case,
+                 the container may escape its own cgroup. (Note also
+                 that if the container has CAP_SYS_ADMIN support
+                 and can mount the cgroup filesystem itself, it may
+                 do so anyway.)
+               </para>
              </listitem>
            </itemizedlist>
            <para>
@@ -1001,20 +1021,20 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, 
Boston, MA 02110-1301 USA
        as command line arguments and through environment variables.
        The arguments are:
        <itemizedlist>
-         <listitem> Container name. </listitem>
-         <listitem> Section (always 'lxc'). </listitem>
-         <listitem> The hook type (i.e. 'clone' or 'pre-mount'). </listitem>
-         <listitem> Additional arguments In the
+         <listitem><para> Container name. </para></listitem>
+         <listitem><para> Section (always 'lxc'). </para></listitem>
+         <listitem><para> The hook type (i.e. 'clone' or 'pre-mount'). 
</para></listitem>
+         <listitem><para> Additional arguments In the
          case of the clone hook, any extra arguments passed to
-         lxc-clone will appear as further arguments to the hook. </listitem>
+         lxc-clone will appear as further arguments to the hook. 
</para></listitem>
        </itemizedlist>
        The following environment variables are set:
        <itemizedlist>
-         <listitem> LXC_NAME: is the container's name. </listitem>
-         <listitem> LXC_ROOTFS_MOUNT: the path to the mounted root filesystem. 
</listitem>
-         <listitem> LXC_CONFIG_FILE: the path to the container configuration 
file. </listitem>
-         <listitem> LXC_SRC_NAME: in the case of the clone hook, this is the 
original container's name. </listitem>
-         <listitem> LXC_ROOTFS_PATH: this is the lxc.rootfs entry for the 
container.  Note this is likely not where the mounted rootfs is to be found, 
use LXC_ROOTFS_MOUNT for that. </listitem>
+         <listitem><para> LXC_NAME: is the container's name. </para></listitem>
+         <listitem><para> LXC_ROOTFS_MOUNT: the path to the mounted root 
filesystem. </para></listitem>
+         <listitem><para> LXC_CONFIG_FILE: the path to the container 
configuration file. </para></listitem>
+         <listitem><para> LXC_SRC_NAME: in the case of the clone hook, this is 
the original container's name. </para></listitem>
+         <listitem><para> LXC_ROOTFS_PATH: this is the lxc.rootfs entry for 
the container.  Note this is likely not where the mounted rootfs is to be 
found, use LXC_ROOTFS_MOUNT for that. </para></listitem>
        </itemizedlist>
       </para>
       <para>
@@ -1121,8 +1141,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, 
Boston, MA 02110-1301 USA
          <listitem>
            <para>
              A hook to be run when the container is cloned to a new one.
-             See <refentrytitle><command>lxc-clone</command></refentrytitle>
-             <manvolnum>1</manvolnum> for more information.
+             See 
<citerefentry><refentrytitle><command>lxc-clone</command></refentrytitle>
+             <manvolnum>1</manvolnum></citerefentry> for more information.
            </para>
          </listitem>
        </varlistentry>
-- 
1.8.1.4


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel

Reply via email to