Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

提交 1652fa2f 编写于 作者: E Eric Blake
浏览文件
操作

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.
上级 7a4bc156
隐藏空白更改
内联 并排
Showing with 136 addition and 133 deletion
.dir-locals.el
浏览文件 @ 1652fa2f
......@@ -5,4 +5,7 @@
(c-indent-level . 4)
(c-basic-offset . 4)
))
(html-mode . (
(indent-tabs-mode . nil)
))
)
cfg.mk
浏览文件 @ 1652fa2f
......@@ -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\
......
docs/formatdomain.html.in
浏览文件 @ 1652fa2f
......@@ -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 &lt;channel&gt; 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>
&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;
......@@ -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' &mdash; default with QEMU/KVM</li>
......
docs/internals.html.in
浏览文件 @ 1652fa2f
......@@ -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>
......
docs/internals/command.html.in
浏览文件 @ 1652fa2f
......@@ -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>
......
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或