[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.

[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.
c02dc9a8 · Andrew Morton · Linus Torvalds · 2b5f9408 · c02dc9a8 · c02dc9a8
Commit c02dc9a8 authored Apr 11, 2004 by Andrew Morton Committed by Linus Torvalds Apr 11, 2004
7 changed files
--- a/Documentation/DocBook/kernel-hacking.tmpl
+++ b/Documentation/DocBook/kernel-hacking.tmpl
@@ -204,11 +204,11 @@
   </para>
   <para>
-    <filename class=headerfile>include/linux/interrupt.h</filename> lists the 
+    <filename class="headerfile">include/linux/interrupt.h</filename> lists the
    different BH's.  No matter how many CPUs you have, no two BHs will run at 
    the same time. This made the transition to SMP simpler, but sucks hard for
    scalable performance.  A very important bottom half is the timer
-    BH (<filename class=headerfile>include/linux/timer.h</filename>): you 
+    BH (<filename class="headerfile">include/linux/timer.h</filename>): you
    can register to have it call functions for you in a given length of time.
   </para>
@@ -224,7 +224,7 @@
   </para>
   <para>
-    tasklets (<filename class=headerfile>include/linux/interrupt.h</filename>) 
+    tasklets (<filename class="headerfile">include/linux/interrupt.h</filename>)
    are like softirqs, except they are dynamically-registrable (meaning you 
    can have as many as you want), and they also guarantee that any tasklet 
    will only run on one CPU at any time, although different tasklets can 
@@ -241,7 +241,7 @@
   <para>
    You can tell you are in a softirq (or bottom half, or tasklet)
    using the <function>in_softirq()</function> macro 
-    (<filename class=headerfile>include/asm/hardirq.h</filename>).
+    (<filename class="headerfile">include/asm/hardirq.h</filename>).
   </para>
   <caution>
    <para>
@@ -330,7 +330,7 @@ asmlinkage long sys_mycall(int arg)
   You create a character device and implement an appropriate ioctl
   for it.  This is much more flexible than system calls, doesn't have
   to be entered in every architecture's
-   <filename class=headerfile>include/asm/unistd.h</filename> and
+   <filename class="headerfile">include/asm/unistd.h</filename> and
   <filename>arch/kernel/entry.S</filename> file, and is much more
   likely to be accepted by Linus.
  </para>
@@ -343,7 +343,7 @@ asmlinkage long sys_mycall(int arg)
  <para>
   Inside the ioctl you're in user context to a process.  When a
   error occurs you return a negated errno (see
-   <filename class=headerfile>include/linux/errno.h</filename>),
+   <filename class="headerfile">include/linux/errno.h</filename>),
   otherwise you return <returnvalue>0</returnvalue>.
  </para>
@@ -429,7 +429,7 @@ cond_resched(); /* Will sleep */
  <sect1 id="routines-printk">
   <title>
    <function>printk()</function>
-    <filename class=headerfile>include/linux/kernel.h</filename>
+    <filename class="headerfile">include/linux/kernel.h</filename>
   </title>
   <para>
@@ -447,7 +447,7 @@ printk(KERN_INFO "i = %u\n", i);
   </programlisting>
   <para>
-    See <filename class=headerfile>include/linux/kernel.h</filename>;
+    See <filename class="headerfile">include/linux/kernel.h</filename>;
    for other KERN_ values; these are interpreted by syslog as the
    level.  Special case: for printing an IP address use
   </para>
@@ -487,7 +487,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
    <function>get_user()</function>
    /
    <function>put_user()</function>
-    <filename class=headerfile>include/asm/uaccess.h</filename>
+    <filename class="headerfile">include/asm/uaccess.h</filename>
   </title>  
   <para>
@@ -525,7 +525,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
  <sect1 id="routines-kmalloc">
   <title><function>kmalloc()</function>/<function>kfree()</function>
-    <filename class=headerfile>include/linux/slab.h</filename></title>
+    <filename class="headerfile">include/linux/slab.h</filename></title>
   <para>
    <emphasis>[MAY SLEEP: SEE BELOW]</emphasis>
@@ -593,10 +593,10 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
   <para>
    If you are allocating at least <constant>PAGE_SIZE</constant>
-    (<filename class=headerfile>include/asm/page.h</filename>) bytes,
+    (<filename class="headerfile">include/asm/page.h</filename>) bytes,
    consider using <function>__get_free_pages()</function>
-    (<filename class=headerfile>include/linux/mm.h</filename>).  It
+    (<filename class="headerfile">include/linux/mm.h</filename>).  It
    takes an order argument (0 for page sized, 1 for double page, 2
    for four pages etc.) and the same memory priority flag word as
    above.
@@ -619,13 +619,13 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
   <para>
    Before inventing your own cache of often-used objects consider
    using a slab cache in
-    <filename class=headerfile>include/linux/slab.h</filename>
+    <filename class="headerfile">include/linux/slab.h</filename>
   </para>
  </sect1>
  <sect1 id="routines-current">
   <title><function>current</function>
-    <filename class=headerfile>include/asm/current.h</filename></title>
+    <filename class="headerfile">include/asm/current.h</filename></title>
   <para>
    This global variable (really a macro) contains a pointer to
@@ -638,8 +638,8 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
  <sect1 id="routines-udelay">
   <title><function>udelay()</function>/<function>mdelay()</function>
-     <filename class=headerfile>include/asm/delay.h</filename> 
+     <filename class="headerfile">include/asm/delay.h</filename>
-     <filename class=headerfile>include/linux/delay.h</filename> 
+     <filename class="headerfile">include/linux/delay.h</filename>
   </title>
   <para>
@@ -652,7 +652,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
  <sect1 id="routines-endian">
   <title><function>cpu_to_be32()</function>/<function>be32_to_cpu()</function>/<function>cpu_to_le32()</function>/<function>le32_to_cpu()</function>
-     <filename class=headerfile>include/asm/byteorder.h</filename> 
+     <filename class="headerfile">include/asm/byteorder.h</filename>
   </title>
   <para>
@@ -675,7 +675,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
  <sect1 id="routines-local-irqs">
   <title><function>local_irq_save()</function>/<function>local_irq_restore()</function>
-    <filename class=headerfile>include/asm/system.h</filename>
+    <filename class="headerfile">include/asm/system.h</filename>
   </title>
   <para>
@@ -690,7 +690,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
  <sect1 id="routines-softirqs">
   <title><function>local_bh_disable()</function>/<function>local_bh_enable()</function>
-    <filename class=headerfile>include/linux/interrupt.h</filename></title>
+    <filename class="headerfile">include/linux/interrupt.h</filename></title>
   <para>
    These routines disable soft interrupts on the local CPU, and
@@ -703,7 +703,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
  <sect1 id="routines-processorids">
   <title><function>smp_processor_id</function>()
-    <filename class=headerfile>include/asm/smp.h</filename></title>
+    <filename class="headerfile">include/asm/smp.h</filename></title>
   <para>
    <function>smp_processor_id()</function> returns the current
@@ -715,7 +715,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
  <sect1 id="routines-init">
   <title><type>__init</type>/<type>__exit</type>/<type>__initdata</type>
-    <filename class=headerfile>include/linux/init.h</filename></title>
+    <filename class="headerfile">include/linux/init.h</filename></title>
   <para>
    After boot, the kernel frees up a special section; functions
@@ -738,7 +738,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
  <sect1 id="routines-init-again">
   <title><function>__initcall()</function>/<function>module_init()</function>
-    <filename class=headerfile>include/linux/init.h</filename></title>
+    <filename class="headerfile">include/linux/init.h</filename></title>
   <para>
    Many parts of the kernel are well served as a module
    (dynamically-loadable parts of the kernel).  Using the
@@ -768,7 +768,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
  <sect1 id="routines-moduleexit">
   <title> <function>module_exit()</function>
-    <filename class=headerfile>include/linux/init.h</filename> </title>
+    <filename class="headerfile">include/linux/init.h</filename> </title>
   <para>
    This macro defines the function to be called at module removal
@@ -781,7 +781,7 @@ printk(KERN_INFO "my ip: %d.%d.%d.%d\n", NIPQUAD(ipaddress));
  <sect1 id="routines-module-use-counters">
   <title> <function>MOD_INC_USE_COUNT</function>/<function>MOD_DEC_USE_COUNT</function>
-    <filename class=headerfile>include/linux/module.h</filename></title>
+    <filename class="headerfile">include/linux/module.h</filename></title>
   <para>
    These manipulate the module usage count, to protect against
@@ -839,7 +839,7 @@ foo_open (...)
 <chapter id="queues">
  <title>Wait Queues
-   <filename class=headerfile>include/linux/wait.h</filename>
+   <filename class="headerfile">include/linux/wait.h</filename>
  </title>
  <para>
   <emphasis>[SLEEPS]</emphasis>
@@ -874,7 +874,7 @@ foo_open (...)
    There is a macro to do this:
    <function>wait_event_interruptible()</function>
-    <filename class=headerfile>include/linux/sched.h</filename> The
+    <filename class="headerfile">include/linux/sched.h</filename> The
    first argument is the wait queue head, and the second is an
    expression which is evaluated; the macro returns
    <returnvalue>0</returnvalue> when this expression is true, or
@@ -900,7 +900,7 @@ foo_open (...)
   <para>
    Call <function>wake_up()</function>
-    <filename class=headerfile>include/linux/sched.h</filename>;,
+    <filename class="headerfile">include/linux/sched.h</filename>;,
    which will wake up every process in the queue.  The exception is
    if one has <constant>TASK_EXCLUSIVE</constant> set, in which case
    the remainder of the queue will not be woken.
@@ -915,7 +915,7 @@ foo_open (...)
   Certain operations are guaranteed atomic on all platforms.  The
   first class of operations work on <type>atomic_t</type>
-   <filename class=headerfile>include/asm/atomic.h</filename>; this
+   <filename class="headerfile">include/asm/atomic.h</filename>; this
   contains a signed integer (at least 24 bits long), and you must use
   these functions to manipulate or read atomic_t variables.
   <function>atomic_read()</function> and
@@ -943,7 +943,7 @@ foo_open (...)
   The second class of atomic operations is atomic bit operations on a
   <type>long</type>, defined in
-   <filename class=headerfile>include/asm/bitops.h</filename>.  These
+   <filename class="headerfile">include/asm/bitops.h</filename>.  These
   operations generally take a pointer to the bit pattern, and a bit
   number: 0 is the least significant bit.
   <function>set_bit()</function>, <function>clear_bit()</function>
@@ -982,7 +982,7 @@ foo_open (...)
  <sect1 id="sym-exportsymbols">
   <title><function>EXPORT_SYMBOL()</function>
-    <filename class=headerfile>include/linux/module.h</filename></title>
+    <filename class="headerfile">include/linux/module.h</filename></title>
   <para>
    This is the classic method of exporting a symbol, and it works
@@ -995,7 +995,7 @@ foo_open (...)
  <sect1 id="sym-exportsymbols-gpl">
   <title><function>EXPORT_SYMBOL_GPL()</function>
-    <filename class=headerfile>include/linux/module.h</filename></title>
+    <filename class="headerfile">include/linux/module.h</filename></title>
   <para>
    Similar to <function>EXPORT_SYMBOL()</function> except that the
@@ -1012,7 +1012,7 @@ foo_open (...)
  <sect1 id="conventions-doublelinkedlist">
   <title>Double-linked lists
-    <filename class=headerfile>include/linux/list.h</filename></title>
+    <filename class="headerfile">include/linux/list.h</filename></title>
   <para>
    There are three sets of linked-list routines in the kernel
@@ -1039,7 +1039,7 @@ foo_open (...)
   <para>
    The filesystem code uses <function>ERR_PTR()</function>
-    <filename class=headerfile>include/linux/fs.h</filename>; to
+    <filename class="headerfile">include/linux/fs.h</filename>; to
    encode a negative error number into a pointer, and
    <function>IS_ERR()</function> and <function>PTR_ERR()</function>
    to get it back out again: avoids a separate pointer parameter for

--- a/Documentation/DocBook/kernel-locking.tmpl
+++ b/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>

--- a/Documentation/DocBook/mousedrivers.tmpl
+++ b/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>

--- a/Documentation/DocBook/parportbook.tmpl
+++ b/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>

--- a/Documentation/DocBook/sis900.tmpl
+++ b/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>

--- a/Documentation/DocBook/via-audio.tmpl
+++ b/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

--- a/Documentation/DocBook/videobook.tmpl
+++ b/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>
+   <table frame="all"><title>Device Types</title>
-   <tgroup cols=3 align=left>
+   <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>
+   <table frame="all"><title>struct video_capability fields</title>
-   <tgroup cols=2 align=left>
+   <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>
+   <table frame="all"><title>struct video_tuner fields</title>
-   <tgroup cols=2 align=left>
+   <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>
+   <table frame="all"><title>struct video_tuner flags</title>
-   <tgroup cols=2 align=left>
+   <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>
+   <table frame="all"><title>struct video_tuner modes</title>
-   <tgroup cols=2 align=left>
+   <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>
+   <table frame="all"><title>struct video_audio fields</title>
-   <tgroup cols=2 align=left>
+   <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>
+   <table frame="all"><title>struct video_audio flags</title>
-   <tgroup cols=2 align=left>
+   <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>
+   <table frame="all"><title>struct video_audio modes</title>
-   <tgroup cols=2 align=left>
+   <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>
+   <table frame="all"><title>Capture Capabilities</title>
-   <tgroup cols=2 align=left>
+   <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>
+   <table frame="all"><title>struct video_channel fields</title>
-   <tgroup cols=2 align=left>
+   <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>
+    <table frame="all"><title>struct video_channel flags</title>
-    <tgroup cols=2 align=left>
+    <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>
+    <table frame="all"><title>struct video_channel types</title>
-    <tgroup cols=2 align=left>
+    <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>
+    <table frame="all"><title>struct video_channel norms</title>
-    <tgroup cols=2 align=left>
+    <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>
+   <table frame="all"><title>Framebuffer Encodings</title>
-   <tgroup cols=2 align=left>
+   <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>
+   <table frame="all"><title>struct video_window fields</title>
-   <tgroup cols=2 align=left>
+   <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>
+   <table frame="all"><title>video_clip fields</title>
-   <tgroup cols=2 align=left>
+   <tgroup cols="2" align="left">
   <tbody>
   <row>
        <entry>x, y</><entry>Co-ordinates relative to the display</>