[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] maint: whitespace cleanup



On 02/04/2011 01:25 PM, Eric Blake wrote:
* cfg.mk (sc_TAB_in_indentation): Check more files.
* .dir-locals.el (html-mode): Let emacs help out.
* docs/internals/command.html.in: Fix offenders.
* docs/formatdomain.html.in: Likewise.
* docs/internals.html.in: Likewise.
Reported by Jiri Denemark.
---

Here's the git diff -b output; actual patch below the diffstat.

ACK. The diff -b verifies no functional changes beyond the ones that will help to take detect / prevent future whitespace problems.

diff --git c/.dir-locals.el w/.dir-locals.el
index 7c483d2..f24ec61 100644
--- c/.dir-locals.el
+++ w/.dir-locals.el
@@ -5,4 +5,7 @@
              (c-indent-level . 4)
              (c-basic-offset . 4)
              ))
+ (html-mode . (
+        (indent-tabs-mode . nil)
+	        ))
   )
diff --git c/cfg.mk w/cfg.mk
index 7664bdf..120f452 100644
--- c/cfg.mk
+++ w/cfg.mk
@@ -322,13 +322,13 @@ sc_prohibit_ctype_h:
    halt="don't use ctype.h; instead, use c-ctype.h"		\
      $(_sc_search_regexp)

-# Ensure that no C source file or rng schema uses TABs for
+# Ensure that no C source file, docs, or rng schema uses TABs for
  # indentation.  Also match *.h.in files, to get libvirt.h.in.  Exclude
  # files in gnulib, since they're imported.
  sc_TAB_in_indentation:
	@prohibit='^ *	'						\
-	in_vc_files='(\.(rng|[ch](\.in)?)|(daemon|tools)/.*\.in)$$'	\
-	halt='use spaces, not TAB, for indentation in C, sh, and RNG schemas' \
+	in_vc_files='(\.(rng|[ch](\.in)?|html.in)|(daemon|tools)/.*\.in)$$' \
+	halt='use leading spaces, not TAB, in C, sh, html, and RNG schemas' \
  	  $(_sc_search_regexp)

  ctype_re = isalnum|isalpha|isascii|isblank|iscntrl|isdigit|isgraph|islower\



  .dir-locals.el                 |    3 +
  cfg.mk                         |    6 +-
  docs/formatdomain.html.in      |  224 ++++++++++++++++++++--------------------
  docs/internals.html.in         |    4 +-
  docs/internals/command.html.in |   32 +++---
  5 files changed, 136 insertions(+), 133 deletions(-)

diff --git a/.dir-locals.el b/.dir-locals.el
index 7c483d2..f24ec61 100644
--- a/.dir-locals.el
+++ b/.dir-locals.el
@@ -5,4 +5,7 @@
              (c-indent-level . 4)
              (c-basic-offset . 4)
              ))
+ (html-mode . (
+	       (indent-tabs-mode . nil)
+	       ))
   )
diff --git a/cfg.mk b/cfg.mk
index 7664bdf..120f452 100644
--- a/cfg.mk
+++ b/cfg.mk
@@ -322,13 +322,13 @@ sc_prohibit_ctype_h:
  	halt="don't use ctype.h; instead, use c-ctype.h"		\
  	  $(_sc_search_regexp)

-# Ensure that no C source file or rng schema uses TABs for
+# Ensure that no C source file, docs, or rng schema uses TABs for
  # indentation.  Also match *.h.in files, to get libvirt.h.in.  Exclude
  # files in gnulib, since they're imported.
  sc_TAB_in_indentation:
  	@prohibit='^ *	'						\
-	in_vc_files='(\.(rng|[ch](\.in)?)|(daemon|tools)/.*\.in)$$'	\
-	halt='use spaces, not TAB, for indentation in C, sh, and RNG schemas' \
+	in_vc_files='(\.(rng|[ch](\.in)?|html.in)|(daemon|tools)/.*\.in)$$' \
+	halt='use leading spaces, not TAB, in C, sh, html, and RNG schemas' \
  	  $(_sc_search_regexp)

  ctype_re = isalnum|isalpha|isascii|isblank|iscntrl|isdigit|isgraph|islower\
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 43c78fc..b048bb5 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -304,20 +304,20 @@
        omitted, it defaults to the OS provided defaults.</dd>
        <dt><code>hard_limit</code></dt>
        <dd>  The optional<code>hard_limit</code>  element is the maximum memory
-	the guest can use. The units for this value are kilobytes (i.e. blocks
-	of 1024 bytes)</dd>
+        the guest can use. The units for this value are kilobytes (i.e. blocks
+        of 1024 bytes)</dd>
        <dt><code>soft_limit</code></dt>
        <dd>  The optional<code>soft_limit</code>  element is the memory limit to
-	enforce during memory contention. The units for this value are
-	kilobytes (i.e. blocks of 1024 bytes)</dd>
+        enforce during memory contention. The units for this value are
+        kilobytes (i.e. blocks of 1024 bytes)</dd>
        <dt><code>swap_hard_limit</code></dt>
        <dd>  The optional<code>swap_hard_limit</code>  element is the maximum
-	swap the guest can use. The units for this value are kilobytes
-	(i.e. blocks of 1024 bytes)</dd>
+        swap the guest can use. The units for this value are kilobytes
+        (i.e. blocks of 1024 bytes)</dd>
        <dt><code>min_guarantee</code></dt>
        <dd>  The optional<code>min_guarantee</code>  element is the guaranteed
-	minimum memory allocation for the guest. The units for this value are
-	kilobytes (i.e. blocks of 1024 bytes)</dd>
+        minimum memory allocation for the guest. The units for this value are
+        kilobytes (i.e. blocks of 1024 bytes)</dd>
        <dt><code>vcpu</code></dt>
        <dd>The content of this element defines the maximum number of virtual
          CPUs allocated for the guest OS, which must be between 1 and
@@ -387,8 +387,8 @@
              match the specification.</dd>
          </dl>

-	<span class="since">Since 0.8.5</span>  the<code>match</code>
-	attribute can be omitted and will default to<code>exact</code>.
+<span class="since">Since 0.8.5</span>  the<code>match</code>
+        attribute can be omitted and will default to<code>exact</code>.
        </dd>

        <dt><code>model</code></dt>
@@ -436,8 +436,8 @@
              CPU.</dd>
          </dl>

-	<span class="since">Since 0.8.5</span>  the<code>policy</code>
-	attribute can be omitted and will default to<code>require</code>.
+<span class="since">Since 0.8.5</span>  the<code>policy</code>
+        attribute can be omitted and will default to<code>require</code>.
        </dd>
      </dl>

@@ -566,101 +566,101 @@
      <dl>
        <dt><code>clock</code></dt>
        <dd>
-	<p>The<code>offset</code>  attribute takes four possible
-	  values, allowing fine grained control over how the guest
-	  clock is synchronized to the host. NB, not all hypervisors
-	  support all modes.</p>
-	<dl>
-	<dt><code>utc</code></dt>
-	<dd>
-	    The guest clock will always be synchronized to UTC when
-	    booted</dd>
-	<dt><code>localtime</code></dt>
-	<dd>
-	    The guest clock will be synchronized to the host's configured
-	    timezone when booted, if any.
-	</dd>
-	<dt><code>timezone</code></dt>
-	<dd>
-	    The guest clock will be synchronized to the requested timezone
-	    using the<code>timezone</code>  attribute.
-	<span class="since">Since 0.7.7</span>
-	</dd>
-	<dt><code>variable</code></dt>
-	<dd>
-	    The guest clock will have an arbitrary offset applied
-	    relative to UTC. The delta relative to UTC is specified
-	    in seconds, using the<code>adjustment</code>  attribute.
-	    The guest is free to adjust the RTC over time an expect
-	    that it will be honoured at next reboot. This is in
-	    contrast to 'utc' mode, where the RTC adjustments are
-	    lost at each reboot.<span class="since">Since 0.7.7</span>
-	</dd>
-	</dl>
-	<p>
-	  A<code>clock</code>  may have zero or more
-	<code>timer</code>sub-elements.<span class="since">Since
-	  0.8.0</span>
-	</p>
+<p>The<code>offset</code>  attribute takes four possible
+          values, allowing fine grained control over how the guest
+          clock is synchronized to the host. NB, not all hypervisors
+          support all modes.</p>
+<dl>
+<dt><code>utc</code></dt>
+<dd>
+            The guest clock will always be synchronized to UTC when
+            booted</dd>
+<dt><code>localtime</code></dt>
+<dd>
+            The guest clock will be synchronized to the host's configured
+            timezone when booted, if any.
+</dd>
+<dt><code>timezone</code></dt>
+<dd>
+            The guest clock will be synchronized to the requested timezone
+            using the<code>timezone</code>  attribute.
+<span class="since">Since 0.7.7</span>
+</dd>
+<dt><code>variable</code></dt>
+<dd>
+            The guest clock will have an arbitrary offset applied
+            relative to UTC. The delta relative to UTC is specified
+            in seconds, using the<code>adjustment</code>  attribute.
+            The guest is free to adjust the RTC over time an expect
+            that it will be honoured at next reboot. This is in
+            contrast to 'utc' mode, where the RTC adjustments are
+            lost at each reboot.<span class="since">Since 0.7.7</span>
+</dd>
+</dl>
+<p>
+          A<code>clock</code>  may have zero or more
+<code>timer</code>sub-elements.<span class="since">Since
+          0.8.0</span>
+</p>
        </dd>
        <dt><code>timer</code></dt>
        <dd>
-	<p>
-	  Each timer element requires a<code>name</code>  attribute,
-	  and has other optional attributes that depend on
-	  the<code>name</code>  specified.  Various hypervisors
-	  support different combinations of attributes.
-	</p>
-	<dl>
-	<dt><code>name</code></dt>
-	<dd>
-	    The<code>name</code>  attribute selects which timer is
-	    being modified, and can be one of "platform", "pit",
-	    "rtc", "hpet", or "tsc".
-	</dd>
-	<dt><code>track</code></dt>
-	<dd>
-	    The<code>track</code>  attribute specifies what the timer
-	    tracks, and can be "boot", "guest", or "wall".
-	    Only valid for<code>name="rtc"</code>
-	    or<code>name="platform"</code>.
-	</dd>
-	<dt><code>tickpolicy</code></dt>
-	<dd>
-	    The<code>tickpolicy</code>  attribute determines how
-	    missed ticks in the guest are handled, and can be "delay",
-	    "catchup", "merge", or "discard".  If the policy is
-	    "catchup", there can be further details in
-	    the<code>catchup</code>  sub-element.
-	<dl>
-	<dt><code>catchup</code></dt>
-	<dd>
-		The<code>catchup</code>  element has three optional
-		attributes, each a positive integer.  The attributes
-		are<code>threshold</code>,<code>slew</code>,
-		and<code>limit</code>.
-	</dd>
-	</dl>
-	</dd>
-	<dt><code>frequency</code></dt>
-	<dd>
-	    The<code>frequency</code>  attribute is an unsigned
-	    integer specifying the frequency at
-	    which<code>name="tsc"</code>  runs.
-	</dd>
-	<dt><code>mode</code></dt>
-	<dd>
-	    The<code>mode</code>  attribute controls how
-	    the<code>name="tsc"</code>  timer is managed, and can be
-	    "auto", "native", "emulate", "paravirt", or "smpsafe".
-	    Other timers are always emulated.
-	</dd>
-	<dt><code>present</code></dt>
-	<dd>
-	    The<code>present</code>  attribute can be "yes" or "no" to
-	    specify whether a particular timer is available to the guest.
-	</dd>
-	</dl>
+<p>
+          Each timer element requires a<code>name</code>  attribute,
+          and has other optional attributes that depend on
+          the<code>name</code>  specified.  Various hypervisors
+          support different combinations of attributes.
+</p>
+<dl>
+<dt><code>name</code></dt>
+<dd>
+            The<code>name</code>  attribute selects which timer is
+            being modified, and can be one of "platform", "pit",
+            "rtc", "hpet", or "tsc".
+</dd>
+<dt><code>track</code></dt>
+<dd>
+            The<code>track</code>  attribute specifies what the timer
+            tracks, and can be "boot", "guest", or "wall".
+            Only valid for<code>name="rtc"</code>
+            or<code>name="platform"</code>.
+</dd>
+<dt><code>tickpolicy</code></dt>
+<dd>
+            The<code>tickpolicy</code>  attribute determines how
+            missed ticks in the guest are handled, and can be "delay",
+            "catchup", "merge", or "discard".  If the policy is
+            "catchup", there can be further details in
+            the<code>catchup</code>  sub-element.
+<dl>
+<dt><code>catchup</code></dt>
+<dd>
+                The<code>catchup</code>  element has three optional
+                attributes, each a positive integer.  The attributes
+                are<code>threshold</code>,<code>slew</code>,
+                and<code>limit</code>.
+</dd>
+</dl>
+</dd>
+<dt><code>frequency</code></dt>
+<dd>
+            The<code>frequency</code>  attribute is an unsigned
+            integer specifying the frequency at
+            which<code>name="tsc"</code>  runs.
+</dd>
+<dt><code>mode</code></dt>
+<dd>
+            The<code>mode</code>  attribute controls how
+            the<code>name="tsc"</code>  timer is managed, and can be
+            "auto", "native", "emulate", "paravirt", or "smpsafe".
+            Other timers are always emulated.
+</dd>
+<dt><code>present</code></dt>
+<dd>
+            The<code>present</code>  attribute can be "yes" or "no" to
+            specify whether a particular timer is available to the guest.
+</dd>
+</dl>
        </dd>
      </dl>

@@ -1490,7 +1490,7 @@ qemu-kvm -net nic,model=? /dev/null
            </dd>
            <dt><code>"spice"</code></dt>
            <dd>
-	<p>
+<p>
    Starts a SPICE server. The<code>port</code>  attribute specifies the TCP
    port number (with -1 as legacy syntax indicating that it should be
    auto-allocated), while<code>tlsPort</code>  gives an alternative
@@ -1502,8 +1502,8 @@ qemu-kvm -net nic,model=? /dev/null
    to use. It is possible to set a limit on the validity of the password
    be giving an timestamp<code>passwdValidTo='2010-04-09T15:51:00'</code>
    assumed to be in UTC. NB, this may not be supported by all hypervisors.
-	</p>
-	<p>
+</p>
+<p>
    When SPICE has both a normal and TLS secured TCP port configured, it
    can be desirable to restrict what channels can be run on each port.
    This is achieved by adding one or more&lt;channel&gt; elements inside
@@ -1511,8 +1511,8 @@ qemu-kvm -net nic,model=? /dev/null
    <code>main</code>,<code>display</code>,<code>inputs</code>,
    <code>cursor</code>,<code>playback</code>,<code>record</code>;
    and<span class="since">since 0.8.8</span>:<code>smartcard</code>.
-	</p>
-	<pre>
+</p>
+<pre>
    &lt;graphics type='spice' port='-1' tlsPort='-1' autoport='yes'&gt;
      &lt;channel name='main' mode='secure'/&gt;
      &lt;channel name='record' mode='insecure'/&gt;
@@ -1569,7 +1569,7 @@ qemu-kvm -net nic,model=? /dev/null
        <dd>
          The<code>model</code>  element has a mandatory<code>type</code>
          attribute which takes the value "vga", "cirrus", "vmvga", "qxl",
-	"xen" or "vbox", depending on the hypervisor features available.
+        "xen" or "vbox", depending on the hypervisor features available.
          You can also provide the amount of video memory in kilobytes using
          <code>vram</code>  and the number of screen with<code>heads</code>.
        </dd>
@@ -2167,8 +2167,8 @@ qemu-kvm -net nic,model=? /dev/null
        <dd>
          <p>
            The required<code>model</code>  attribute specifies what type
-	  of balloon device is provided. Valid values are specific to
-	  the virtualization platform
+          of balloon device is provided. Valid values are specific to
+          the virtualization platform
          </p>
          <ul>
            <li>'virtio'&mdash; default with QEMU/KVM</li>
diff --git a/docs/internals.html.in b/docs/internals.html.in
index dc88eab..6fa2de3 100644
--- a/docs/internals.html.in
+++ b/docs/internals.html.in
@@ -10,10 +10,10 @@

      <ul>
        <li>Introduction to basic rules and guidelines for<a href="hacking.html">hacking<a>
-	    on libvirt code</li>
+            on libvirt code</li>
        <li>Guide to adding<a href="api_extension.html">public APIs<a></li>
        <li>Approach for<a href="internals/command.html">spawning commands</a>  from
-	libvirt driver code</li>
+        libvirt driver code</li>
      </ul>

    </body>
diff --git a/docs/internals/command.html.in b/docs/internals/command.html.in
index 95d2b81..27dcf9c 100644
--- a/docs/internals/command.html.in
+++ b/docs/internals/command.html.in
@@ -20,27 +20,27 @@

      <ul>
        <li><code>fork+exec</code>: The lowest&amp; most flexible
-	level, but very hard to use correctly / safely. It
-	is easy to leak file descriptors, have unexpected
-	signal handler behaviour and not handle edge cases.
-	Furthermore, it is not portable to mingw.
-	</li>
+        level, but very hard to use correctly / safely. It
+        is easy to leak file descriptors, have unexpected
+        signal handler behaviour and not handle edge cases.
+        Furthermore, it is not portable to mingw.
+</li>
        <li><code>system</code>: Convenient if you don't care
-	about capturing command output, but has the serious
-	downside that the command string is interpreted by
-	the shell. This makes it very dangerous to use, because
-	improperly validated user input can lead to exploits
-	via shell meta characters.
+        about capturing command output, but has the serious
+        downside that the command string is interpreted by
+        the shell. This makes it very dangerous to use, because
+        improperly validated user input can lead to exploits
+        via shell meta characters.
        </li>
        <li><code>popen</code>: Inherits the flaws of
-	<code>system</code>, and has no option for bi-directional
-	communication.
+<code>system</code>, and has no option for bi-directional
+        communication.
        </li>
        <li><code>posix_spawn</code>: A half-way house between
-	simplicity of system() and the flexibility of fork+exec.
-	It does not allow for a couple of important features
-	though, such as running a hook between the fork+exec
-	stage, or closing all open file descriptors.</li>
+        simplicity of system() and the flexibility of fork+exec.
+        It does not allow for a couple of important features
+        though, such as running a hook between the fork+exec
+        stage, or closing all open file descriptors.</li>
      </ul>

      <p>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]