[libvirt] [PATCH] maint: whitespace cleanup
Eric Blake
eblake at redhat.com
Fri Feb 4 18:25:52 UTC 2011
* 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.
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 <channel> 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>
<graphics type='spice' port='-1' tlsPort='-1' autoport='yes'>
<channel name='main' mode='secure'/>
<channel name='record' mode='insecure'/>
@@ -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' — 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 & 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>
--
1.7.4
More information about the libvir-list
mailing list