diff --git a/.dir-locals.el b/.dir-locals.el index 7c483d2dcb..f24ec617c9 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 7664bdf69d..120f452bc0 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 417a8a2737..9f7a1133d1 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -317,20 +317,20 @@ omitted, it defaults to the OS provided defaults.
hard_limit
The optional hard_limit element is the maximum memory - the guest can use. The units for this value are kilobytes (i.e. blocks - of 1024 bytes)
+ the guest can use. The units for this value are kilobytes (i.e. blocks + of 1024 bytes)
soft_limit
The optional soft_limit element is the memory limit to - enforce during memory contention. The units for this value are - kilobytes (i.e. blocks of 1024 bytes)
+ enforce during memory contention. The units for this value are + kilobytes (i.e. blocks of 1024 bytes)
swap_hard_limit
The optional swap_hard_limit element is the maximum - swap the guest can use. The units for this value are kilobytes - (i.e. blocks of 1024 bytes)
+ swap the guest can use. The units for this value are kilobytes + (i.e. blocks of 1024 bytes)
min_guarantee
The optional min_guarantee element is the guaranteed - minimum memory allocation for the guest. The units for this value are - kilobytes (i.e. blocks of 1024 bytes)
+ minimum memory allocation for the guest. The units for this value are + kilobytes (i.e. blocks of 1024 bytes)
vcpu
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.
- Since 0.8.5 the match - attribute can be omitted and will default to exact. + Since 0.8.5 the match + attribute can be omitted and will default to exact.
model
@@ -449,8 +449,8 @@ CPU. - Since 0.8.5 the policy - attribute can be omitted and will default to require. + Since 0.8.5 the policy + attribute can be omitted and will default to require. @@ -579,101 +579,101 @@
clock
-

The offset 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.

-
-
utc
-
- The guest clock will always be synchronized to UTC when - booted
-
localtime
-
- The guest clock will be synchronized to the host's configured - timezone when booted, if any. -
-
timezone
-
- The guest clock will be synchronized to the requested timezone - using the timezone attribute. - Since 0.7.7 -
-
variable
-
- The guest clock will have an arbitrary offset applied - relative to UTC. The delta relative to UTC is specified - in seconds, using the adjustment 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. Since 0.7.7 -
-
-

- A clock may have zero or more - timersub-elements. Since - 0.8.0 -

+

The offset 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.

+
+
utc
+
+ The guest clock will always be synchronized to UTC when + booted
+
localtime
+
+ The guest clock will be synchronized to the host's configured + timezone when booted, if any. +
+
timezone
+
+ The guest clock will be synchronized to the requested timezone + using the timezone attribute. + Since 0.7.7 +
+
variable
+
+ The guest clock will have an arbitrary offset applied + relative to UTC. The delta relative to UTC is specified + in seconds, using the adjustment 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. Since 0.7.7 +
+
+

+ A clock may have zero or more + timersub-elements. Since + 0.8.0 +

timer
-

- Each timer element requires a name attribute, - and has other optional attributes that depend on - the name specified. Various hypervisors - support different combinations of attributes. -

-
-
name
-
- The name attribute selects which timer is - being modified, and can be one of "platform", "pit", - "rtc", "hpet", or "tsc". -
-
track
-
- The track attribute specifies what the timer - tracks, and can be "boot", "guest", or "wall". - Only valid for name="rtc" - or name="platform". -
-
tickpolicy
-
- The tickpolicy 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 catchup sub-element. -
-
catchup
-
- The catchup element has three optional - attributes, each a positive integer. The attributes - are threshold, slew, - and limit. -
-
-
-
frequency
-
- The frequency attribute is an unsigned - integer specifying the frequency at - which name="tsc" runs. -
-
mode
-
- The mode attribute controls how - the name="tsc" timer is managed, and can be - "auto", "native", "emulate", "paravirt", or "smpsafe". - Other timers are always emulated. -
-
present
-
- The present attribute can be "yes" or "no" to - specify whether a particular timer is available to the guest. -
-
+

+ Each timer element requires a name attribute, + and has other optional attributes that depend on + the name specified. Various hypervisors + support different combinations of attributes. +

+
+
name
+
+ The name attribute selects which timer is + being modified, and can be one of "platform", "pit", + "rtc", "hpet", or "tsc". +
+
track
+
+ The track attribute specifies what the timer + tracks, and can be "boot", "guest", or "wall". + Only valid for name="rtc" + or name="platform". +
+
tickpolicy
+
+ The tickpolicy 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 catchup sub-element. +
+
catchup
+
+ The catchup element has three optional + attributes, each a positive integer. The attributes + are threshold, slew, + and limit. +
+
+
+
frequency
+
+ The frequency attribute is an unsigned + integer specifying the frequency at + which name="tsc" runs. +
+
mode
+
+ The mode attribute controls how + the name="tsc" timer is managed, and can be + "auto", "native", "emulate", "paravirt", or "smpsafe". + Other timers are always emulated. +
+
present
+
+ The present attribute can be "yes" or "no" to + specify whether a particular timer is available to the guest. +
+
@@ -1503,7 +1503,7 @@ qemu-kvm -net nic,model=? /dev/null
"spice"
-

+

Starts a SPICE server. The port attribute specifies the TCP port number (with -1 as legacy syntax indicating that it should be auto-allocated), while tlsPort 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 passwdValidTo='2010-04-09T15:51:00' assumed to be in UTC. NB, this may not be supported by all hypervisors. -

-

+

+

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 main, display, inputs, cursor, playback, record; and since 0.8.8: smartcard. -

- 
+            

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

         The model element has a mandatory type
         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
         vram and the number of screen with heads.
       

@@ -2180,8 +2180,8 @@ qemu-kvm -net nic,model=? /dev/null
       

         

           The required model 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
         

         
    
           
  • 'virtio' — default with QEMU/KVM
    • 
diff --git a/docs/internals.html.in b/docs/internals.html.in
index dc88eab9b7..6fa2de33ab 100644
--- a/docs/internals.html.in
+++ b/docs/internals.html.in
@@ -10,10 +10,10 @@
 
     
 
   
diff --git a/docs/internals/command.html.in b/docs/internals/command.html.in
index 95d2b815df..27dcf9c4d8 100644
--- a/docs/internals/command.html.in
+++ b/docs/internals/command.html.in
@@ -20,27 +20,27 @@
 
     
      
       
    • fork+exec: 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.
-	
      • 
+        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.
+        
       
    • system: 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.
       
      • 
       
    • popen: Inherits the flaws of
-	system, and has no option for bi-directional
-	communication.
+        system, and has no option for bi-directional
+        communication.
       
      • 
       
    • posix_spawn: 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.
      • 
+        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.