[PATCH] Consistently use quotes for SGML attributes

From: Rusty Russell <rusty@rustcorp.com.au>

From:  Hans Ulrich Niedermann <linux-kernel@n-dimensional.de>

doc patch: Consistently use quotes for SGML attributes This makes it
possible to process the SGML files without SHORTTAG YES.

Documentation/DocBook/kernel-locking.tmpl

@@ -87,7 +87,7 @@
     <table>
      <title>Expected Results</title>
 
-     <tgroup cols=2 align=left>
+     <tgroup cols="2" align="left">
 
       <thead>
        <row>
@@ -133,7 +133,7 @@
     <table>
      <title>Possible Results</title>
 
-     <tgroup cols=2 align=left>
+     <tgroup cols="2" align="left">
       <thead>
        <row>
         <entry>Instance 1</entry>
@@ -222,14 +222,14 @@
    <para>
      There are two main types of kernel locks.  The fundamental type
      is the spinlock 
-     (<filename class=headerfile>include/asm/spinlock.h</filename>), 
+     (<filename class="headerfile">include/asm/spinlock.h</filename>),
      which is a very simple single-holder lock: if you can't get the 
      spinlock, you keep trying (spinning) until you can.  Spinlocks are 
      very small and fast, and can be used anywhere.
    </para>
    <para>
      The second type is a semaphore
-     (<filename class=headerfile>include/asm/semaphore.h</filename>): it
+     (<filename class="headerfile">include/asm/semaphore.h</filename>): it
      can have more than one holder at any time (the number decided at
      initialization time), although it is most commonly used as a
      single-holder lock (a mutex).  If you can't get a semaphore,
@@ -315,7 +315,7 @@
       user context can be interrupted by a softirq, and secondly, the
       critical region could be entered from another CPU.  This is where
       <function>spin_lock_bh()</function> 
-      (<filename class=headerfile>include/linux/spinlock.h</filename>) is 
+      (<filename class="headerfile">include/linux/spinlock.h</filename>) is
       used.  It disables softirqs on that CPU, then grabs the lock.
       <function>spin_unlock_bh()</function> does the reverse.  (The
       '_bh' suffix is a historical reference to "Bottom Halves", the
@@ -333,7 +333,7 @@
       This works perfectly for <firstterm linkend="gloss-up"><acronym>UP
       </acronym></firstterm> as well: the spin lock vanishes, and this macro 
       simply becomes <function>local_bh_disable()</function>
-      (<filename class=headerfile>include/linux/interrupt.h</filename>), which
+      (<filename class="headerfile">include/linux/interrupt.h</filename>), which
       protects you from the softirq being run.
     </para>
    </sect1>
@@ -463,7 +463,7 @@
     <para>
       This works perfectly for UP as well: the spin lock vanishes,
       and this macro simply becomes <function>local_irq_disable()</function>
-      (<filename class=headerfile>include/asm/smp.h</filename>), which 
+      (<filename class="headerfile">include/asm/smp.h</filename>), which
       protects you from the softirq/tasklet/BH being run.
     </para>
 
@@ -545,7 +545,7 @@
    </para>
    <table>
 <title>Table of Locking Requirements</title>
-<TGROUP COLS=11>
+<TGROUP COLS="11">
 <TBODY>
 <ROW>
 <ENTRY></ENTRY>
@@ -1026,7 +1026,7 @@ In practice, <type>atomic_t</type> would usually be used for
 <structfield>refcnt</structfield>.  There are a number of atomic
 operations defined in
 
-<filename class=headerfile>include/asm/atomic.h</filename>: these are
+<filename class="headerfile">include/asm/atomic.h</filename>: these are
 guaranteed to be seen atomically from all CPUs in the system, so no
 lock is required.  In this case, it is simpler than using spinlocks,
 although for anything non-trivial using spinlocks is clearer.  The
@@ -1296,7 +1296,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>.
     <table>
      <title>Consequences</title>
 
-     <tgroup cols=2 align=left>
+     <tgroup cols="2" align="left">
 
       <thead>
        <row>
@@ -1437,7 +1437,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>.
       themselves (by calling <function>add_timer()</function> at the end
       of their timer function).  Because this is a fairly common case
       which is prone to races, you should use <function>del_timer_sync()</function>
-      (<filename class=headerfile>include/linux/timer.h</filename>)
+      (<filename class="headerfile">include/linux/timer.h</filename>)
       to handle this case.  It returns the number of times the timer
       had to be deleted before we finally stopped it from adding itself back
       in.
@@ -1749,7 +1749,7 @@ machines due to caching.
       an exclusive lock.  See <function>DEFINE_PER_CPU()</function>,
       <function>get_cpu_var()</function> and
       <function>put_cpu_var()</function>
-      (<filename class=headerfile>include/linux/percpu.h</filename>).
+      (<filename class="headerfile">include/linux/percpu.h</filename>).
     </para>
 
     <para>
@@ -1757,7 +1757,7 @@ machines due to caching.
       <type>local_t</type> type, and the
       <function>cpu_local_inc()</function> and related functions,
       which are more efficient than simple code on some architectures
-      (<filename class=headerfile>include/asm/local.h</filename>).
+      (<filename class="headerfile">include/asm/local.h</filename>).
     </para>
 
     <para>

Documentation/DocBook/mousedrivers.tmpl

@@ -88,9 +88,9 @@
     Each read from a bus mouse interface device returns a block of data. 
     The first three bytes of each read are defined as follows: 
 
-   <table frame=all>
+   <table frame="all">
     <title>Mouse Data Encoding</title>
-    <tgroup cols=2 align=left>
+    <tgroup cols="2" align="left">
      <tbody>
       <row>
        <entry>Byte 0</entry>

Documentation/DocBook/parportbook.tmpl

@@ -969,7 +969,7 @@ port->ops->write_data (port, d);
   <para>
    To recap, then:</para>
 
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
 
    <listitem>
     <para>
@@ -1387,7 +1387,7 @@ struct parport_operations {
     <filename>/dev/parport0</filename>) allows you to:
    </para>
 
-   <itemizedlist spacing=compact>
+   <itemizedlist spacing="compact">
 
     <listitem>
      <para>
@@ -1614,7 +1614,7 @@ struct parport_operations {
 	<filename>incluce/linux/parport.h</filename> and include:
        </para>
 
-       <itemizedlist spacing=compact>
+       <itemizedlist spacing="compact">
 	<listitem><para>
 	  <constant>IEEE1284_MODE_COMPAT</constant></para></listitem>
 	<listitem><para>
@@ -1713,7 +1713,7 @@ struct parport_operations {
 	affect future I/O operations.  Available flags are:
        </para>
 
-       <itemizedlist spacing=compact>
+       <itemizedlist spacing="compact">
 	<listitem><para>
 	  <constant>PP_FASTWRITE</constant></para></listitem>
 	<listitem><para>
@@ -1759,7 +1759,7 @@ struct parport_operations {
 	<filename>include/linux/parport.h</filename>:
        </para>
 
-       <itemizedlist spacing=compact>
+       <itemizedlist spacing="compact">
 	<listitem><para>
 	  <constant>PARPORT_CONTROL_STROBE</constant></para></listitem>
 	  <listitem><para>

Documentation/DocBook/sis900.tmpl

@@ -336,7 +336,7 @@ Those packages are listed in Document/Changes in kernel source
 distribution. If you have to install the driver other than those bundled
 in kernel release, you should have your driver file 
 <filename>sis900.c</filename> and <filename>sis900.h</filename> 
-copied into <filename class=directory>/usr/src/linux/drivers/net/</filename> first.
+copied into <filename class="directory">/usr/src/linux/drivers/net/</filename> first.
 There are two alternative ways to install the driver
 </Para>
 

Documentation/DocBook/via-audio.tmpl

@@ -227,7 +227,7 @@
 <sect1 id="version191"><title>
 Version 1.9.1
 </title>
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
    <listitem>
     <para>
     DSP read/write bugfixes from Thomas Sailer.
@@ -252,7 +252,7 @@ Version 1.9.1
 <sect1 id="version1115"><title>
 Version 1.1.15
 </title>
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
    <listitem>
     <para>
     Support for variable fragment size and variable fragment number (Rui
@@ -325,7 +325,7 @@ Version 1.1.15
 <sect1 id="version1114"><title>
 Version 1.1.14
 </title>
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
    <listitem>
     <para>
     Use VM_RESERVE when available, to eliminate unnecessary page faults.
@@ -337,7 +337,7 @@ Version 1.1.14
 <sect1 id="version1112"><title>
 Version 1.1.12
 </title>
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
    <listitem>
     <para>
     mmap bug fixes from Linus.
@@ -349,7 +349,7 @@ Version 1.1.12
 <sect1 id="version1111"><title>
 Version 1.1.11
 </title>
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
    <listitem>
     <para>
     Many more bug fixes.  mmap enabled by default, but may still be buggy.
@@ -368,7 +368,7 @@ Version 1.1.11
 <sect1 id="version1110"><title>
 Version 1.1.10
 </title>
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
    <listitem>
     <para>
     Many bug fixes.  mmap enabled by default, but may still be buggy.
@@ -380,7 +380,7 @@ Version 1.1.10
 <sect1 id="version119"><title>
 Version 1.1.9
 </title>
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
    <listitem>
     <para>
     Redesign and rewrite audio playback implementation.  (faster and smaller, hopefully)
@@ -478,7 +478,7 @@ Version 1.1.9
 <sect1 id="version118"><title>
 Version 1.1.8
 </title>
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
    <listitem>
     <para>
     	Clean up interrupt handler output.  Fixes the following kernel error message:
@@ -501,7 +501,7 @@ Version 1.1.8
 <sect1 id="version117"><title>
 Version 1.1.7
 </title>
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
    <listitem>
     <para>
  Fix module unload bug where mixer device left registered
@@ -514,7 +514,7 @@ Version 1.1.7
 <sect1 id="version116"><title>
 Version 1.1.6
 </title>
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
    <listitem>
     <para>
  Rewrite via_set_rate to mimic ALSA basic AC97 rate setting
@@ -546,7 +546,7 @@ Version 1.1.6
 <sect1 id="version115"><title>
 Version 1.1.5
 </title>
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
    <listitem>
     <para>
  Disable some overly-verbose debugging code
@@ -573,7 +573,7 @@ Version 1.1.5
 <sect1 id="version114"><title>
 Version 1.1.4
 </title>
-  <itemizedlist spacing=compact>
+  <itemizedlist spacing="compact">
    <listitem>
     <para>
  Completed rewrite of driver.  Eliminated SoundBlaster compatibility

Documentation/DocBook/videobook.tmpl

@@ -176,8 +176,8 @@ int __init myradio_init(struct video_init *v)
   <para>
         The types available are
   </para>
-   <table frame=all><title>Device Types</title>
-   <tgroup cols=3 align=left>
+   <table frame="all"><title>Device Types</title>
+   <tgroup cols="3" align="left">
    <tbody>
    <row>
         <entry>VFL_TYPE_RADIO</><entry>/dev/radio{n}</><entry>
@@ -299,8 +299,8 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
         allows the applications to find out what sort of a card they have found and
         to figure out what they want to do about it. The fields in the structure are
   </para>
-   <table frame=all><title>struct video_capability fields</title>
-   <tgroup cols=2 align=left>
+   <table frame="all"><title>struct video_capability fields</title>
+   <tgroup cols="2" align="left">
    <tbody>
    <row>
         <entry>name</><entry>The device text name. This is intended for the user.</>
@@ -373,8 +373,8 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
   <para>
         The video_tuner structure has the following fields
   </para>
-   <table frame=all><title>struct video_tuner fields</title>
-   <tgroup cols=2 align=left>
+   <table frame="all"><title>struct video_tuner fields</title>
+   <tgroup cols="2" align="left">
    <tbody>
    <row>
         <entry>int tuner</><entry>The number of the tuner in question</entry>
@@ -406,8 +406,8 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
     </tgroup>
     </table>
 
-   <table frame=all><title>struct video_tuner flags</title>
-   <tgroup cols=2 align=left>
+   <table frame="all"><title>struct video_tuner flags</title>
+   <tgroup cols="2" align="left">
    <tbody>
    <row>
 	<entry>VIDEO_TUNER_PAL</><entry>A PAL TV tuner</entry>
@@ -429,8 +429,8 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
     </tgroup>
     </table>
 
-   <table frame=all><title>struct video_tuner modes</title>
-   <tgroup cols=2 align=left>
+   <table frame="all"><title>struct video_tuner modes</title>
+   <tgroup cols="2" align="left">
    <tbody>
    <row>
                 <entry>VIDEO_MODE_PAL</><entry>PAL Format</entry>
@@ -580,8 +580,8 @@ static int current_volume=0;
   <para>
         Then we fill in the video_audio structure. This has the following format
   </para>
-   <table frame=all><title>struct video_audio fields</title>
-   <tgroup cols=2 align=left>
+   <table frame="all"><title>struct video_audio fields</title>
+   <tgroup cols="2" align="left">
    <tbody>
    <row>
    <entry>audio</><entry>The input the user wishes to query</>
@@ -615,8 +615,8 @@ static int current_volume=0;
    </tgroup>
    </table>
 
-   <table frame=all><title>struct video_audio flags</title>
-   <tgroup cols=2 align=left>
+   <table frame="all"><title>struct video_audio flags</title>
+   <tgroup cols="2" align="left">
    <tbody>
    <row>
                 <entry>VIDEO_AUDIO_MUTE</><entry>The audio is currently muted. We
@@ -633,8 +633,8 @@ static int current_volume=0;
    </tgroup>
    </table>
 
-   <table frame=all><title>struct video_audio modes</title>
-   <tgroup cols=2 align=left>
+   <table frame="all"><title>struct video_audio modes</title>
+   <tgroup cols="2" align="left">
    <tbody>
    <row>
                 <entry>VIDEO_SOUND_MONO</><entry>Mono sound</entry>
@@ -862,8 +862,8 @@ static struct video_device my_camera
         We use the extra video capability flags that did not apply to the
         radio interface. The video related flags are
   </para>
-   <table frame=all><title>Capture Capabilities</title>
-   <tgroup cols=2 align=left>
+   <table frame="all"><title>Capture Capabilities</title>
+   <tgroup cols="2" align="left">
    <tbody>
    <row>
 <entry>VID_TYPE_CAPTURE</><entry>We support image capture</>
@@ -1204,8 +1204,8 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
         inputs to the video card). Our example card has a single camera input. The
         fields in the structure are
   </para>
-   <table frame=all><title>struct video_channel fields</title>
-   <tgroup cols=2 align=left>
+   <table frame="all"><title>struct video_channel fields</title>
+   <tgroup cols="2" align="left">
    <tbody>
    <row>
 
@@ -1227,8 +1227,8 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
     </tbody>
     </tgroup>
     </table>
-    <table frame=all><title>struct video_channel flags</title>
-    <tgroup cols=2 align=left>
+    <table frame="all"><title>struct video_channel flags</title>
+    <tgroup cols="2" align="left">
     <tbody>
     <row>
         <entry>VIDEO_VC_TUNER</><entry>Channel has a tuner.</entry>
@@ -1238,8 +1238,8 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
     </tbody>
     </tgroup>
     </table>
-    <table frame=all><title>struct video_channel types</title>
-    <tgroup cols=2 align=left>
+    <table frame="all"><title>struct video_channel types</title>
+    <tgroup cols="2" align="left">
     <tbody>
     <row>
         <entry>VIDEO_TYPE_TV</><entry>Television input.</entry>
@@ -1251,8 +1251,8 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
     </tbody>
     </tgroup>
     </table>
-    <table frame=all><title>struct video_channel norms</title>
-    <tgroup cols=2 align=left>
+    <table frame="all"><title>struct video_channel norms</title>
+    <tgroup cols="2" align="left">
     <tbody>
     <row>
         <entry>VIDEO_MODE_PAL</><entry>PAL encoded Television</entry>
@@ -1337,8 +1337,8 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
         for every other pixel in the image. The other common formats the interface 
         defines are
   </para>
-   <table frame=all><title>Framebuffer Encodings</title>
-   <tgroup cols=2 align=left>
+   <table frame="all"><title>Framebuffer Encodings</title>
+   <tgroup cols="2" align="left">
    <tbody>
    <row>
    <entry>GREY</><entry>Linear greyscale. This is for simple cameras and the
@@ -1475,8 +1475,8 @@ static struct video_buffer capture_fb;
         display. The video_window structure is used to describe the way the image 
         should be displayed. 
    </para>
-   <table frame=all><title>struct video_window fields</title>
-   <tgroup cols=2 align=left>
+   <table frame="all"><title>struct video_window fields</title>
+   <tgroup cols="2" align="left">
    <tbody>
    <row>
         <entry>width</><entry>The width in pixels of the desired image. The card
@@ -1512,8 +1512,8 @@ static struct video_buffer capture_fb;
     <para>
         Each clip is a struct video_clip which has the following fields
    </para>
-   <table frame=all><title>video_clip fields</title>
-   <tgroup cols=2 align=left>
+   <table frame="all"><title>video_clip fields</title>
+   <tgroup cols="2" align="left">
    <tbody>
    <row>
         <entry>x, y</><entry>Co-ordinates relative to the display</>