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