
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.


---

 25-akpm/Documentation/DocBook/kernel-hacking.tmpl |   66 +++++++++++-----------
 25-akpm/Documentation/DocBook/kernel-locking.tmpl |   26 ++++----
 25-akpm/Documentation/DocBook/mousedrivers.tmpl   |    4 -
 25-akpm/Documentation/DocBook/parportbook.tmpl    |   10 +--
 25-akpm/Documentation/DocBook/sis900.tmpl         |    2 
 25-akpm/Documentation/DocBook/via-audio.tmpl      |   24 ++++----
 25-akpm/Documentation/DocBook/videobook.tmpl      |   64 ++++++++++-----------
 7 files changed, 98 insertions(+), 98 deletions(-)

diff -puN Documentation/DocBook/kernel-hacking.tmpl~docbook-sgml-quotes-fix Documentation/DocBook/kernel-hacking.tmpl
--- 25/Documentation/DocBook/kernel-hacking.tmpl~docbook-sgml-quotes-fix	2004-04-03 03:00:00.203200664 -0800
+++ 25-akpm/Documentation/DocBook/kernel-hacking.tmpl	2004-04-03 03:00:00.217198536 -0800
@@ -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",
     <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",
 
   <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",
 
    <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",
    <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",
 
   <sect1 id="routines-udelay">
    <title><function>udelay()</function>/<function>mdelay()</function>
-     <filename class=headerfile>include/asm/delay.h</filename> 
-     <filename class=headerfile>include/linux/delay.h</filename> 
+     <filename class="headerfile">include/asm/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",
  
   <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",
 
   <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",
 
   <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",
 
   <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",
 
   <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",
 
   <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",
   
   <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",
 
   <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
diff -puN Documentation/DocBook/kernel-locking.tmpl~docbook-sgml-quotes-fix Documentation/DocBook/kernel-locking.tmpl
--- 25/Documentation/DocBook/kernel-locking.tmpl~docbook-sgml-quotes-fix	2004-04-03 03:00:00.205200360 -0800
+++ 25-akpm/Documentation/DocBook/kernel-locking.tmpl	2004-04-03 03:00:00.220198080 -0800
@@ -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
 <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 
     <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 
       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>
diff -puN Documentation/DocBook/mousedrivers.tmpl~docbook-sgml-quotes-fix Documentation/DocBook/mousedrivers.tmpl
--- 25/Documentation/DocBook/mousedrivers.tmpl~docbook-sgml-quotes-fix	2004-04-03 03:00:00.206200208 -0800
+++ 25-akpm/Documentation/DocBook/mousedrivers.tmpl	2004-04-03 03:00:00.221197928 -0800
@@ -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>
diff -puN Documentation/DocBook/parportbook.tmpl~docbook-sgml-quotes-fix Documentation/DocBook/parportbook.tmpl
--- 25/Documentation/DocBook/parportbook.tmpl~docbook-sgml-quotes-fix	2004-04-03 03:00:00.208199904 -0800
+++ 25-akpm/Documentation/DocBook/parportbook.tmpl	2004-04-03 03:00:00.224197472 -0800
@@ -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>
diff -puN Documentation/DocBook/sis900.tmpl~docbook-sgml-quotes-fix Documentation/DocBook/sis900.tmpl
--- 25/Documentation/DocBook/sis900.tmpl~docbook-sgml-quotes-fix	2004-04-03 03:00:00.209199752 -0800
+++ 25-akpm/Documentation/DocBook/sis900.tmpl	2004-04-03 03:00:00.224197472 -0800
@@ -336,7 +336,7 @@ Those packages are listed in Document/Ch
 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>
 
diff -puN Documentation/DocBook/via-audio.tmpl~docbook-sgml-quotes-fix Documentation/DocBook/via-audio.tmpl
--- 25/Documentation/DocBook/via-audio.tmpl~docbook-sgml-quotes-fix	2004-04-03 03:00:00.210199600 -0800
+++ 25-akpm/Documentation/DocBook/via-audio.tmpl	2004-04-03 03:00:00.226197168 -0800
@@ -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
diff -puN Documentation/DocBook/videobook.tmpl~docbook-sgml-quotes-fix Documentation/DocBook/videobook.tmpl
--- 25/Documentation/DocBook/videobook.tmpl~docbook-sgml-quotes-fix	2004-04-03 03:00:00.212199296 -0800
+++ 25-akpm/Documentation/DocBook/videobook.tmpl	2004-04-03 03:00:00.228196864 -0800
@@ -176,8 +176,8 @@ int __init myradio_init(struct video_ini
   <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_devi
         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_devi
   <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_devi
     </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_devi
     </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_dev
         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_dev
     </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_dev
     </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_dev
     </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_dev
         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</>

_
