mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-22 05:35:25 +00:00
maint: whitespace cleanup
* .dir-locals.el (html-mode): Let emacs help out. * cfg.mk (sc_TAB_in_indentation): Check more files. * docs/internals/command.html.in: Fix offenders. * docs/formatdomain.html.in: Likewise. * docs/internals.html.in: Likewise. Reported by Jiri Denemark.
This commit is contained in:
Eric Blake
parent
7a4bc156c1
commit
1652fa2fd2
@ -5,4 +5,7 @@
|
||||
(c-indent-level . 4)
|
||||
(c-basic-offset . 4)
|
||||
))
|
||||
(html-mode . (
|
||||
(indent-tabs-mode . nil)
|
||||
))
|
||||
)
|
||||
|
||||
6
cfg.mk
6
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\
|
||||
|
||||
@ -317,20 +317,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
|
||||
@ -400,8 +400,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>
|
||||
@ -449,8 +449,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>
|
||||
|
||||
@ -579,101 +579,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>
|
||||
|
||||
@ -1503,7 +1503,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
|
||||
@ -1515,8 +1515,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
|
||||
@ -1524,8 +1524,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'/>
|
||||
@ -1582,7 +1582,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>
|
||||
@ -2180,8 +2180,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>
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user