The following series flushes my documentation queue and replaces previous postings of those patches. The main difference is that the xl cfg file is now formatted using POD instead of markdown and presented as a manpage. I have setup a cron job to build docs/html and publish it at http://xenbits.xen.org/docs/unstable/ (it''s a bit bare right now). The motivation for some of these patches e.g. creating an index was more to support this use case although it is probably useful for packaging /usr/share/doc/xen etc. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 01 of 17] Replace references to old wiki with ones to new
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540451 0
# Node ID 14a8af47bf11e9e4be35a0000336b49da95d9860
# Parent dbdc840f8f62db58321b5009e5e0f7833066386f
Replace references to old wiki with ones to new.
I have confirmed that the relevant pages have been transitioned.
What remains is pages which have not yet been moved over:
$ rgrep xenwiki *
docs/misc/xenstore.txt: See http://wiki.xensource.com/xenwiki/XenBus section
tools/libxen/README:http://wiki.xensource.com/xenwiki/XenApi
tools/xenballoon/xenballoond.README:http://wiki.xensource.com/xenwiki/Open_Topics_For_Discussion?action=AttachFile&do=get&target=Memory+Overcommit.pdf
Note that "PythonInXlConfig" never existed in the old wiki and does
not exist
in the new. This reference was introduced by 22735:cb94dbe20f97 and was
supposed to have been written prior to the 4.1 release. I have transitioned it
anyway but it''s not clear how valuable the message actually is. Perhaps
we
should just remove that aspect of it?
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r dbdc840f8f62 -r 14a8af47bf11 README
--- a/README Wed Nov 16 18:21:14 2011 +0000
+++ b/README Thu Nov 17 14:34:11 2011 +0000
@@ -59,10 +59,10 @@ provided by your OS distributor:
Second, you need to acquire a suitable kernel for use in domain 0. If
possible you should use a kernel provided by your OS distributor. If
no suitable kernel is available from your OS distributor then refer to
-http://wiki.xen.org/xenwiki/XenDom0Kernels for suggestions for
+http://wiki.xen.org/wiki/XenDom0Kernels for suggestions for
suitable kernels to use.
If you are looking to compile a Dom0 kernel from source, please refer to
-http://wiki.xensource.com/xenwiki/XenParavirtOps.
+http://wiki.xensource.com/wiki/XenParavirtOps.
[NB. Unless noted otherwise, all the following steps should be
performed with root privileges.]
diff -r dbdc840f8f62 -r 14a8af47bf11 docs/misc/vtd.txt
--- a/docs/misc/vtd.txt Wed Nov 16 18:21:14 2011 +0000
+++ b/docs/misc/vtd.txt Thu Nov 17 14:34:11 2011 +0000
@@ -184,7 +184,7 @@ http://www.dell.com/content/products/cat
- HP Compaq: DC7800
http://h10010.www1.hp.com/wwpc/us/en/en/WF04a/12454-12454-64287-321860-3328898.html
-For more information, pls refer to http://wiki.xensource.com/xenwiki/VTdHowTo.
+For more information, pls refer to http://wiki.xensource.com/wiki/VTdHowTo.
Assigning devices to HVM domains
diff -r dbdc840f8f62 -r 14a8af47bf11 docs/misc/xl-network-configuration.markdown
--- a/docs/misc/xl-network-configuration.markdown Wed Nov 16 18:21:14 2011 +0000
+++ b/docs/misc/xl-network-configuration.markdown Thu Nov 17 14:34:11 2011 +0000
@@ -123,4 +123,4 @@ defaults to domain 0. Specifying another
driver domain which is outside the scope of this document.
[oui]: http://en.wikipedia.org/wiki/Organizationally_Unique_Identifier
-[net]: http://wiki.xen.org/xenwiki/HostConfiguration/Networking
+[net]: http://wiki.xen.org/wiki/HostConfiguration/Networking
diff -r dbdc840f8f62 -r 14a8af47bf11 docs/src/interface.tex
--- a/docs/src/interface.tex Wed Nov 16 18:21:14 2011 +0000
+++ b/docs/src/interface.tex Thu Nov 17 14:34:11 2011 +0000
@@ -1579,7 +1579,7 @@ This contains links to the latest versio
documentation, including the latest version of the FAQ.
Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xensource.com/wiki/}\end{quote}
The Xen project uses Bugzilla as its bug tracking system. You''ll find
the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
diff -r dbdc840f8f62 -r 14a8af47bf11 docs/src/user.tex
--- a/docs/src/user.tex Wed Nov 16 18:21:14 2011 +0000
+++ b/docs/src/user.tex Thu Nov 17 14:34:11 2011 +0000
@@ -2349,7 +2349,7 @@ This contains links to the latest versio
documentation, including the latest version of the FAQ.
Information regarding Xen is also available at the Xen Wiki at
-\begin{quote} {\tt http://wiki.xensource.com/xenwiki/}\end{quote}
+\begin{quote} {\tt http://wiki.xensource.com/wiki/}\end{quote}
The Xen project uses Bugzilla as its bug tracking system. You''ll find
the Xen Bugzilla at http://bugzilla.xensource.com/bugzilla/.
diff -r dbdc840f8f62 -r 14a8af47bf11 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c Wed Nov 16 18:21:14 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c Thu Nov 17 14:34:11 2011 +0000
@@ -72,7 +72,7 @@ static void parse(CfgParseContext *ctx)
fputs(
"warning: Config file looks like it contains Python code.\n"
"warning: Arbitrary Python is no longer supported.\n"
- "warning: See http://wiki.xen.org/xenwiki/PythonInXlConfig\n",
+ "warning: See http://wiki.xen.org/wiki/PythonInXlConfig\n",
ctx->cfg->report);
}
}
diff -r dbdc840f8f62 -r 14a8af47bf11 xen/common/sched_credit2.c
--- a/xen/common/sched_credit2.c Wed Nov 16 18:21:14 2011 +0000
+++ b/xen/common/sched_credit2.c Thu Nov 17 14:34:11 2011 +0000
@@ -51,7 +51,7 @@
/*
* WARNING: This is still in an experimental phase. Status and work can be
found at the
* credit2 wiki page:
- * http://wiki.xensource.com/xenwiki/Credit2_Scheduler_Development
+ * http://wiki.xensource.com/wiki/Credit2_Scheduler_Development
* TODO:
* + Immediate bug-fixes
* - Do per-runqueue, grab proper lock for dump debugkey
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 02 of 17] docs: xlexample.hvm is missing "builder = ''hvm''"
# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1321540451 0 # Node ID 5e3e5757de0fcd0b826d0ca8330db7fa1cfccba4 # Parent 14a8af47bf11e9e4be35a0000336b49da95d9860 docs: xlexample.hvm is missing "builder = ''hvm''" This is rather critical... Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 14a8af47bf11 -r 5e3e5757de0f tools/examples/xlexample.hvm --- a/tools/examples/xlexample.hvm Thu Nov 17 14:34:11 2011 +0000 +++ b/tools/examples/xlexample.hvm Thu Nov 17 14:34:11 2011 +0000 @@ -5,6 +5,9 @@ # This is a fairly minimal example of what is required for an # HVM guest. For a more complete guide see <XXX Document TBD> +# This configures an HVM rather than PV guest +builder = "hvm" + # Guest name name = "example.hvm" _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 03 of 17] README: add markdown to dependency list
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540451 0
# Node ID e8f0094323d0edcf8e35573f37b74beab5694bd3
# Parent 5e3e5757de0fcd0b826d0ca8330db7fa1cfccba4
README: add markdown to dependency list
although this tool is strictly speaking optional we are providing various user
docs in this format so increase the changes that they will install it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r 5e3e5757de0f -r e8f0094323d0 README
--- a/README Thu Nov 17 14:34:11 2011 +0000
+++ b/README Thu Nov 17 14:34:11 2011 +0000
@@ -55,6 +55,7 @@ provided by your OS distributor:
* GNU gettext
* 16-bit x86 assembler, loader and compiler (dev86 rpm or bin86 & bcc
debs)
* ACPI ASL compiler (iasl)
+ * markdown
Second, you need to acquire a suitable kernel for use in domain 0. If
possible you should use a kernel provided by your OS distributor. If
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 04 of 17] docs: install html and txt versions of manpages
# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1321540451 0 # Node ID f3fc909a083ddcea05cd0c9ab51a7241e573f6a6 # Parent e8f0094323d0edcf8e35573f37b74beab5694bd3 docs: install html and txt versions of manpages Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r e8f0094323d0 -r f3fc909a083d docs/Docs.mk --- a/docs/Docs.mk Thu Nov 17 14:34:11 2011 +0000 +++ b/docs/Docs.mk Thu Nov 17 14:34:11 2011 +0000 @@ -5,6 +5,8 @@ FIG2DEV := fig2dev LATEX2HTML := latex2html DOXYGEN := doxygen POD2MAN := pod2man +POD2HTML := pod2html +POD2TEXT := pod2text DOT := dot NEATO := neato MARKDOWN := markdown diff -r e8f0094323d0 -r f3fc909a083d docs/Makefile --- a/docs/Makefile Thu Nov 17 14:34:11 2011 +0000 +++ b/docs/Makefile Thu Nov 17 14:34:11 2011 +0000 @@ -15,9 +15,13 @@ DOC_MARKDOWN := $(wildcard misc/*.markdo DOC_PS := $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX)) DOC_PDF := $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX)) DOC_HTML := $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \ - $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) + $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \ + $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \ + $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC)) DOC_TXT := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \ - $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) + $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \ + $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \ + $(patsubst man/%.pod.5,txt/man/%.5.txt,$(DOC_MAN5SRC)) GFX = $(patsubst %.fig, %.eps, $(wildcard figs/*.fig)) @@ -76,7 +80,7 @@ clean: $(MAKE) -C xen-api clean rm -rf .word_count *.aux *.dvi *.bbl *.blg *.glo *.idx *~ rm -rf *.ilg *.log *.ind *.toc *.bak core - rm -rf $(GFX) ps pdf html + rm -rf $(GFX) ps pdf html txt rm -rf api rm -rf man5 rm -rf man1 @@ -132,6 +136,16 @@ html/%.html: %.markdown $(call move-if-changed,$@.tmp,$@) ; else \ echo "markdown not installed; skipping $*.html."; fi +html/man/%.1.html: man/%.pod.1 Makefile + $(INSTALL_DIR) $(@D) + $(POD2HTML) --infile=$< --outfile=$@.tmp + $(call move-if-changed,$@.tmp,$@) + +html/man/%.5.html: man/%.pod.5 Makefile + $(INSTALL_DIR) $(@D) + $(POD2HTML) --infile=$< --outfile=$@.tmp + $(call move-if-changed,$@.tmp,$@) + txt/%.txt: %.txt $(INSTALL_DIR) $(@D) cp $< $@.tmp @@ -141,3 +155,14 @@ txt/%.txt: %.markdown $(INSTALL_DIR) $(@D) cp $< $@.tmp $(call move-if-changed,$@.tmp,$@) + +txt/man/%.1.txt: man/%.pod.1 Makefile + $(INSTALL_DIR) $(@D) + $(POD2TEXT) $< $@.tmp + $(call move-if-changed,$@.tmp,$@) + +txt/man/%.5.txt: man/%.pod.5 Makefile + $(INSTALL_DIR) $(@D) + $(POD2TEXT) $< $@.tmp + $(call move-if-changed,$@.tmp,$@) + _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 05 of 17] docs: add a document describing the xl cfg file syntax
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540524 0
# Node ID c88ff1ac24170a7d2a3c8824735ef9311eb95fe0
# Parent f3fc909a083ddcea05cd0c9ab51a7241e573f6a6
docs: add a document describing the xl cfg file syntax
Based on an initial version by Ian Jackson.
I believe that all keys are now present in the document although there are are
various omissions in the actual documentation of them. Hopefully however this
covers the majority of the most interesting keys.
Spice section:
Signed-off-by: Zhou Peng <zhoupeng@nfs.iscas.ac.cn>
The rest:
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r f3fc909a083d -r c88ff1ac2417 docs/man/xl.cfg.pod.5
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/man/xl.cfg.pod.5 Thu Nov 17 14:35:24 2011 +0000
@@ -0,0 +1,844 @@
+=head1 NAME
+
+xl.cfg - XL Domain Configuration File Syntax
+
+=head1 SYNOPSIS
+
+ /etc/xen/xldomain
+
+=head1 DESCRIPTION
+
+To create a VM (a domain in Xen terminology, sometimes called a guest)
+with xl requires the provision of a domain config file. Typically
+these live in `/etc/xen/DOMAIN.cfg` where DOMAIN is the name of the
+domain.
+
+=head1 SYNTAX
+
+A domain config file consists of a series of C<KEY=VALUE> pairs.
+
+Some C<KEY>s are mandatory, others are global options which apply to
+any guest type while others relate only to specific guest types
+(e.g. PV or HVM guests).
+
+A value C<VALUE> is one of:
+
+=over 4
+
+=item B<"STRING">
+
+A string, surrounded by either single or double quotes.
+
+=item B<NUMBER>
+
+A number, in either decimal, octal (using a C<0> prefix) or
+hexadecimal (using an C<0x> prefix).
+
+=item B<BOOLEAN>
+
+A C<NUMBER> interpreted as C<False> (C<0>) or C<True>
(any other
+value).
+
+=item B<[ VALUE, VALUE, ... ]>
+
+A list of C<VALUES> of the above types. Lists are homogeneous and are
+not nested.
+
+=back
+
+The semantics of each C<KEY> defines which form of C<VALUE> is
required.
+
+=head1 OPTIONS
+
+=head2 Mandatory Configuration Items
+
+The following key is mandatory for any guest type:
+
+=over 4
+
+=item B<name="NAME">
+
+Specifies the name of the domain. Names of domains existing on a
+single host must be unique.
+
+=back
+
+=head2 Selecting Guest Type
+
+=over 4
+
+=item B<builder="generic">
+
+Specifies that this is to be a PV domain. This is the default.
+
+=item B<builder="hvm">
+
+Specifies that this is to be an HVM domain. That is, a fully
+virtualised computer with emulated BIOS, disk and network peripherals,
+etc. The default is a PV domain, suitable for hosting Xen-aware guest
+operating systems.
+
+=back
+
+=head2 Global Options
+
+The following options apply to guests of any type.
+
+=over 4
+
+=item B<uuid="UUID">
+
+Specifies the UUID of the domain. If not specified, a fresh unique
+UUID will be generated.
+
+=item B<pool="CPUPOOLNAME">
+
+Put the guest''s vcpus into the named cpu pool.
+
+=item B<vcpus=N>
+
+Start the guest with N vcpus initially online.
+
+=item B<maxvcpus=M>
+
+Allow the guest to bring up a maximum of M vcpus. At start of day if
+`vcpus=N` is less than `maxvcpus=M` then the first `N` vcpus will be
+created online and the remainder will be offline.
+
+=item B<memory=MBYTES>
+
+Start the guest with MBYTES megabytes of RAM.
+
+=item B<on_poweroff="ACTION">
+
+Specifies what should be done with the domain if it shuts itself down.
+The C<ACTION>s are:
+
+=over 4
+
+=item B<destroy>
+
+destroy the domain
+
+=item B<restart>
+
+destroy the domain and immediately create a new domain with the same
+configuration
+
+=item B<rename-restart>
+
+rename the domain which terminated, and thenimmediately create a new
+domain with the same configuration as the original
+
+=item B<preserve>
+
+keep the domain. It can be examined, and later destroyed with `xl
+destroy`.
+
+=item B<coredump-destroy>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and
then
+destroy the domain.
+
+=item B<coredump-restart>
+
+write a "coredump" of the domain to F</var/xen/dump/NAME> and
then
+restart the domain.
+
+=back
+
+The default for C<on_poweroff> is C<destroy>.
+
+=item B<on_reboot="ACTION">
+
+Action to take if the domain shuts down with a reason code requesting
+a reboot. Default is C<restart>.
+
+=item B<on_watchdog="ACTION">
+
+Action to take if the domain shuts down due to a Xen watchdog timeout.
+Default is C<destroy>.
+
+=item B<on_crash="ACTION">
+
+Action to take if the domain crashes. Default is C<destroy>.
+
+=item B<seclabel="LABEL">
+
+Assign an XSM security label to this domain.
+
+=back
+
+=head2 Devices
+
+The following options define the paravirtual, emulated and physical
+devices which the guest will contain.
+
+=over 4
+
+=item B<disk=[ "DISK_SPEC_STRING", "DISK_SPEC_STRING",
...]>
+
+Specifies the disks (both emulated disks and Xen virtual block
+devices) which are to be provided to the guest, and what objects on
+the they should map to. See F<docs/misc/xl-disk-configuration.txt>.
+
+=item B<vif=[ "NET_SPEC_STRING", "NET_SPEC_STRING",
...]>
+
+Specifies the networking provision (both emulated network adapters,
+and Xen virtual interfaces) to provided to the guest. See
+F<docs/misc/xl-network-configuration.markdown>.
+
+=item B<vfb=[ "VFB_SPEC_STRING", "VFB_SPEC_STRING",
...]>
+
+Specifies the paravirtual framebuffer devices which should be supplied
+to the domain.
+
+This options does not control the emulated graphics card presented to
+an HVM guest. See L<Emulated VGA Graphics Device> below for how to
+configure the emulated device.
+
+Each B<VFB_SPEC_STRING> is a comma-separated list of C<KEY=VALUE>
+settings, from the following list:
+
+=over 4
+
+=item C<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol. This enables the
+other VNC-related settings. The default is to enable this.
+
+=item C<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item C<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use. The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item C<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item C<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item C<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is to not enable this mode
+
+=item C<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using C<device_model_version="qemu-xen-traditonal"> and only if
the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item C<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below or consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item C<display=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=item C<authority=XXX>
+
+XXX written to xenstore backend for vfb but does not appear to be used
+anywhere?
+
+=back
+
+=item B<pci=[ "PCI_SPEC_STRING", "PCI_SPEC_STRING", ...
]>
+
+Specifies the host PCI devices to passthrough to this guest. Each
B<PCI_SPEC_STRING>
+has the form C<[DDDD:]BB:DD.F[@VSLOT],KEY=VALUE,KEY=VALUE,...> where:
+
+=over 4
+
+=item B<DDDD:BB:DD.F>
+
+identifies the PCI device from the host perspective in domain
+(B<DDDD>), Bus (B<BB>), Device (B<DD>) and Function
(B<F>) syntax. This is
+the same scheme as used in the output of C<lspci> for the device in
+question. Note: By default C<lspci> will omit the domain (B<DDDD>)
if it
+is zero and it is optional here also. You may specify the function
+(B<F>) as B<*> to indicate all functions.
+
+=item B<@VSLOT>
+
+specifies the virtual device where the guest will see this
+device. This is equivalent to the B<DD> which the guest sees. In a
+guest B<DDDD> and B<BB> are C<0000:00>. XXX how does this
really work?
+
+=item B<KEY=VALUE>
+
+Posible B<KEY>s are:
+
+=over 4
+
+=item B<msitranslate=BOOLEAN>
+
+XXX
+
+=item B<power_mgmt=BOOLEAN>
+
+XXX
+
+=back
+
+=back
+
+=back
+
+=head2 Paravirtualised (PV) Guest Specific Options
+
+The following options apply only to Paravirtual guests.
+
+=over 4
+
+=item B<kernel="PATHNAME">
+
+Load the specified file as the kernel image. Either B<kernel> or
+B<bootloader> must be specified for PV guests.
+
+=item B<ramdisk="PATHNAME">
+
+Load the specified file as the ramdisk.
+
+=item B<bootloader="PROGRAM">
+
+Run C<PROGRAM> to find the kernel image and ramdisk to use. Normally
+C<PROGRAM> would be C<pygrub>, which is an emulation of
+grub/grub2/syslinux.
+
+=item B<bootloader_args=STRING>
+
+Append B<STRING> (split into words at whitespace) to the arguments to
+the B<bootloader> program. XXX this should be a list of strings.
+
+=item B<root="STRING">
+
+Append B<root="STRING"> to the kernel command line (Note: it is
guest
+specific what meaning this has).
+
+=item B<extra="STRING">
+
+Append B<STRING> to the kernel command line. Note: it is guest
+specific what meaning this has).
+
+=item B<e820_host=BOOLEAN>
+
+Selects whether to expose the host e820 (memory map) to the guest via
+the virtual e820. When this option is false the guest psuedo-physical
+address space consists of a single contiguous RAM region. When this
+option is specified the virtual e820 instead reflects the host e820
+and contains the same PCI holes. The total amount of RAM represented
+by the memory map is always the same, this option configures only how
+it is layed out.
+
+Exposing the host e820 to the guest gives the guest kernel the
+opportunity to set aside the required part of its pseudo-physical
+address space in order to provide address space to map passedthrough
+PCI devices. It is guest Operaring System dependant whether this
+option is required, specifically it is required when using a mainline
+Linux ("pvops") kernel. This option defaults to true if any PCI
+passthrough devices are configued and false otherwise. If you do not
+configure any passthrough devices at domain creation time but expect
+to hotplug devices later then you should set this option. Conversely
+if your particular guest kernel does not require this behaviour then
+it is safe to allow this to be enabled but you may wish to disable it
+anyway.
+
+=back
+
+=head2 Fully-virtualised (HVM) Guest Specific Options
+
+The following options apply only to HVM guests.
+
+=head3 Boot Device
+
+=over 4
+
+=item B<boot=[c|d|n]>
+
+Selects the emulated virtual device to boot from. Options are hard
+disk (B<c>), cd-rom (B<d>) or network/PXE (B<n>). Multiple
options can be
+given and will be attempted in the order they are given. e.g. to boot
+from cd-rom but fallback to the hard disk you can give B<dc>. The
+default is B<cd>.
+
+=back
+
+=head3 Paging
+
+The following options control the mechanisms used to virtualise guest
+memory. The defaults are selected to give the best results for the
+common case and so you should normally leave these options
+unspecified.
+
+=over 4
+
+=item B<hap=BOOLEAN>
+
+Turns "hardware assisted paging" (the use of the hardware nested page
+table feature) on or off. This feature is called EPT (Extended Page
+Tables) by Intel and NPT (Nested Page Tables) or RVI (Rapid
+Virtualisation Indexing) by AMD. Affects HVM guests only. If turned
+off, Xen will run the guest in "shadow page table" mode where the
+guest''s page table updates and/or TLB flushes etc. will be emulated.
+Use of HAP is the default when available.
+
+=item B<oos=BOOLEAN>
+
+Turns "out of sync pagetables" on or off. When running in shadow
page
+table mode, the guest''s page table updates may be deferred as
+specified in the Intel/AMD architecture manuals. However this may
+expose unexpected bugs in the guest, or find bugs in Xen, so it is
+possible to disable this feature. Use of out of sync page tables,
+when Xen thinks it appropriate, is the default.
+
+=item B<shadow_memory=MBYTES>
+
+Number of megabytes to set aside for shadowing guest pagetable pages
+(effectively acting as a cache of translated pages) or to use for HAP
+state. By default this is 1MB per guest vcpu plus 8KB per MB of guest
+RAM. You should not normally need to adjust this value. However if you
+are not using hardware assisted paging (i.e. you are using shadow
+mode) and your guest workload consists of a a very large number of
+similar processes then increasing this value may improve performance.
+
+=back
+
+=head3 Processor and Platform Features
+
+The following options allow various processor and platform level
+features to be hidden or exposed from the guest''s point of view. This
+can be useful when running older guest Operating Systems which may
+misbehave when faced with more modern features. In general you should
+accept the defaults for these options wherever possible.
+
+=over 4
+
+=item B<pae=BOOLEAN>
+
+Hide or expose the IA32 Physical Address Extensions. These extensions
+make it possible for a 32 bit guest Operating System to access more
+than 4GB of RAM. Enabling PAE also enabled other features such as
+NX. PAE is required if you wish to run a 64-bit guest Operating
+System. In general you should leave this enabled and allow the guest
+Operating System to choose whether or not to use PAE. (X86 only)
+
+=item B<acpi=BOOLEAN>
+
+Expose ACPI (Advanced Configuration and Power Interface) tables from
+the virtual firmware to the guest Operating System. ACPI is required
+by most modern guest Operating Systems. This option is enabled by
+default and usually you should omit it. However it may be necessary to
+disable ACPI for compatibility with some guest Operating Systems.
+
+=item B<apic=BOOLEAN>
+
+Include information regarding APIC (Advanced Programmable Interrupt
+Controller) in the firmware/BIOS tables on a single processor
+guest. This causes the MP (multiprocessor) and PIR (PCI Interrupt
+Routing) tables to be exported by the virtual firmware. This option
+has no effect on a guest with multiple virtual CPUS as they must
+always include these tables. This option is enabled by default and you
+should usually omit it but it may be necessary to disable these
+firmware tables when using certain older guest Operating
+Systems. These tables have been superceded by newer constructs within
+the ACPI tables. (X86 only)
+
+=item B<nx=BOOLEAN>
+
+Hides or exposes the No-eXecute capability. This allows a guest
+Operating system to map pages such that they cannot be executed which
+can enhance security. This options requires that PAE also be
+enabled. (X86 only)
+
+=item B<hpet=BOOLEAN>
+
+Enables or disables HPET (High Precision Event Timer). This option is
+enabled by default and you should usually omit it. It may be necessary
+to disable the HPET in order to improve compatibility with guest
+Operating Systems (X86 only)
+
+=item B<nestedhvm=BOOLEAN>
+
+Enable or disables guest access to hardware virtualisation features,
+e.g. it allows a guest Operating System to also function as a
+hypervisor. This option is disabled by default. You may want this
+option if you want to run another hypervisor (including another copy
+of Xen) within a Xen guest or to support a guest Operating System
+which uses hardware virtualisation extensions (e.g. Windows XP
+compatibility mode on more modern Windows OS).
+
+=back
+
+=head3 Guest Virtual Time Controls
+
+=over 4
+
+=item B<tsc_mode="MODE">
+
+Specifies how the TSC (Time Stamp Counter) should be provided to the
+guest. XXX ???
+
+=back
+
+=head3 Support for Paravirtualisation of HVM Guests
+
+The following options allow Paravirtualised features (such as devices)
+to be exposed to the guest Operating System in an HVM guest.
+Utilising these features requires specific guest support but when
+available they will result in improved performance.
+
+=over 4
+
+=item B<xen_platform_pci=BOOLEAN>
+
+Enable or disable the Xen platform PCI device. The presence of this
+virtual device enables a guest Operating System (subject to the
+availability of suitable drivers) to make use of paravirtualisation
+features such as disk and network devices etc. Enabling these drivers
+improves performance and is strongly recommended when available. PV
+drivers are available for various Operating Systems including HVM
+Linux L<http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers> and Microsoft
+Windows L<http://wiki.xen.org/wiki/XenWindowsGplPv>.
+
+=item B<viridian=BOOLEAN>
+
+Turns on or off the exposure of MicroSoft Hyper-V (AKA viridian)
+compatible enlightenments to the guest. These can improve performance
+of Microsoft Windows guests (XXX which versions of Windows benefit?)
+
+=back
+
+=head3 Emulated VGA Graphics Device
+
+The following options control the features of the emulated graphics
+device. Many of these options behave similarly to the equivalent key
+in the B<VFB_SPEC_STRING> for configuring virtual frame buffer devices
+(see above).
+
+=over 4
+
+=item B<videoram=MBYTES>
+
+Sets the amount of RAM which the emulated video card will contain,
+which in turn limits the resolutions and bit depths which will be
+available. This option is only available when using the B<stdvga>
+option (see below). The default is 8MB which is sufficient for
+e.g. 1600x1200 at 32bpp. When not using the B<stdvga> option the
+amount of video ram is fixed at 4MB which is sufficient for 1024x768
+at 32 bpp.
+
+=item B<stdvga=BOOLEAN>
+
+Select a standard VGA card with VBE (VESA BIOS Extensions) as the
+emulated graphics device. The default is false which means to emulate
+a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or
+later (e.g. Windows XP onwards) then you should enable this.
+
+=item B<vnc=BOOLEAN>
+
+Allow access to the display via the VNC protocol. This enables the
+other VNC-related settings. The default is to enable this.
+
+=item B<vnclisten="ADDRESS[:DISPLAYNUM]">
+
+Specifies the IP address, and optionally VNC display number, to use.
+
+=item B<vncdisplay=DISPLAYNUM>
+
+Specifies the VNC display number to use. The actual TCP port number
+will be DISPLAYNUM+5900.
+
+=item B<vncunused=BOOLEAN>
+
+Requests that the VNC display setup search for a free TCP port to use.
+The actual display used can be accessed with C<xl vncviewer>.
+
+=item B<vncpasswd="PASSWORD">
+
+Specifies the password for the VNC server.
+
+=item B<keymap="LANG">
+
+Configure the keymap to use for the keyboard associated with this
+display. If the input method does not easily support raw keycodes
+(e.g. this is often the case when using VNC) then this allows us to
+correctly map the input keys into keycodes seen by the guest. The
+specific values which are accepted are defined by the version of the
+device-model which you are using. See L<Keymaps> below of consult the
+L<qemu(1)> manpage. The default is B<en-us>.
+
+=item B<sdl=BOOLEAN>
+
+Specifies that the display should be presented via an X window (using
+Simple DirectMedia Layer). The default is not to enable this mode.
+
+=item B<opengl=BOOLEAN>
+
+Enable OpenGL acceleration of the SDL display. Only effects machines
+using B<device_model_version="qemu-xen-traditonal"> and only if
the
+device-model was compiled with OpenGL support. Disabled by default.
+
+=item B<nographic=BOOLEAN>
+
+Enable or disable the virtual graphics device. The default is to
+provide a VGA graphics device but this option can be used to disable
+it.
+
+=back
+
+=head3 Spice Graphics Support
+
+The following options control the features of SPICE.
+
+=over 4
+
+=item B<spice=BOOLEAN>
+
+Allow access to the display via the SPICE protocol. This enables the
+other SPICE-related settings.
+
+=item B<spicehost="ADDRESS">
+
+Specify the interface address to listen on if given, otherwise any
+interface.
+
+=item B<spiceport=NUMBER>
+
+Specify the port to listen on by the SPICE server if the SPICE is
+enabled.
+
+=item B<spicetls_port=NUMBER>
+
+Specify the secure port to listen on by the SPICE server if the SPICE
+is enabled. At least one of the spiceport or spicetls_port must be
+given if SPICE is enabled. NB. the options depending on spicetls_port
+have not been supported.
+
+=item B<spicedisable_ticketing=BOOLEAN>
+
+Enable client connection without password. The default is false. If
+it''s false (set to 0), spicepasswd must be set.
+
+=item B<spicepasswd="PASSWORD">
+
+Specify the ticket password which is used by a client for connection.
+
+=item B<spiceagent_mouse=BOOLEAN>
+
+Whether SPICE agent is used for client mouse mode. The default is true
+(turn on)
+
+=back
+
+=head3 Miscellaneous Emulated Hardware
+
+=over 4
+
+=item B<serial=DEVICE>
+
+Redirect the virtual serial port to B<DEVICE>. Please see the
+B<-serial> option in the L<qemu(1)> manpage for details of the
valid
+B<DEVICE> options. Default is B<vc> when in graphical mode and
+B<stdio> if B<nographics=1> is used.
+
+=item B<soundhw=DEVICE>
+
+Select the virtual sound card to expose to the guest. The valid
+devices are defined by the device model configuration, please see the
+L<qemu(1)> manpage for details. The default is not to export any sound
+device.
+
+=item B<usb=BOOLEAN>
+
+Enables or disables a USB bus in the guest.
+
+=item B<usbdevice=DEVICE>
+
+Adds B<DEVICE> to the USB bus. The USB bus must also be enabled using
+B<usb=1>. The most common use for this option is
B<usbdevice=tablet>
+which adds pointer device using absolute coordinates. Such devices
+function better than relative coordinate devices (such as a standard
+mouse) since many methods of exporting guest graphics (such as VNC)
+work better in this mode. Note that this is independent of the actual
+pointer device you are using on the host/client side. XXX should/could
+be a list of devices.
+
+=back
+
+=head3 Unclassified HVM Specific Options
+
+These HVM specific options have not yet been documented or
+classified. They almost certainly belong in a more appropriate
+section.
+
+=over 4
+
+=item B<vpt_align=BOOLEAN>
+
+Align the Virtual Platform Timer ??? XXX Reduces interrupts?
+
+=item B<timer_mode=NUMBER>
+
+Set mode for Virtual Timers XXX ??? should be an enum of particular
+values. See C<HVM_PARAM_TIMER_MODE> in
+F<xen/include/public/hvm/params.h>.
+
+=back
+
+=head2 Device-Model Options
+
+The following options control the selection of the device-model. This
+is the component which provides emulation of the virtual devices to an
+HVM guest. For a PV guest a device-model is sometimes used to provide
+backends for certain PV devices (most usually a virtual framebuffer
+device).
+
+=over 4
+
+=item B<device_model_version="DEVICE-MODEL">
+
+Selects which variant of the device-model should be used for this
+guest. Valid values are:
+
+=over 4
+
+=item B<qemu-xen-traditional>
+
+Use the device-model based upon the historical Xen fork of Qemu. This
+device-model is currently the default.
+
+=item B<qemu-xen>
+
+use the device-model merged into the upstream Qemu project. This
+device-model will become the default in a future version of Xen.
+
+=back
+
+It is recommended to accept the default value for new guests. If
+you have existing guests then, depeending on the nature of the guest
+Operating System, you may wish to force them to use the device
+model which they were installed with.
+
+=item B<device_model_override="PATH">
+
+Override the path to the binary to be used as the device-model. The
+binary provided here MUST be consistent with the
+`device_model_version` which you have specified. You should not
+normally need to specify this option.
+
+=item B<device_model_stubdomain_override=BOOLEAN>
+
+Override the use of stubdomain based device-model. Normally this will
+be automatically selected based upon the other features and options
+you have selected.
+
+=item B<device_model_args=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command
+line. Each element in the list is passed as an option to the
+device-model.
+
+=item B<device_model_args_pv=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+a PV device model only. Each element in the list is passed as an
+option to the device-model.
+
+=item B<device_model_args_hvm=[ "ARG", "ARG", ...]>
+
+Pass additional arbitrary options on the devide-model command line for
+an HVM device model only. Each element in the list is passed as an
+option to the device-model.
+
+=back
+
+=head2 Unclassified General Options
+
+These have not yet been fully documented or classified. They almost
+certainly belong in a more appropriate section.
+
+=over 4
+
+=item B<gfx_passthrough=BOOLEAN>
+
+Enable graphics device PCI passthrough. XXX which device is passed through ?
+
+=item B<nomigrate=BOOLEAN>
+
+Disable migration of this domain. This enables certain other features
+which are incompatible with migration (currently certain TSC modes XXX
+?).
+
+=item B<pci_msitranslate=BOOLEAN>
+
+XXX
+
+=item B<pci_power_mgmt=BOOLEAN>
+
+XXX
+
+=item B<cpuid=XXX>
+
+XXX
+
+=back
+
+=head2 Keymaps
+
+The keymaps available are defined by the device-model which you are
+using. Commonly this includes:
+
+ ar de-ch es fo fr-ca hu ja mk no pt-br sv
+ da en-gb et fr fr-ch is lt nl pl ru th
+ de en-us fi fr-be hr it lv nl-be pt sl tr
+
+The default is B<en-us>.
+
+See L<qemu(1)> for more information.
+
+=head1 SEE ALSO
+
+=over 4
+
+=item L<xl(1)>
+
+=item F<xl-disk-configuration>
+
+=item F<xl-network-configuration>
+
+=back
+
+=head1 FILES
+
+F</etc/xen/NAME.cfg>
+F</var/xen/dump/NAME>
+F<docs/misc/tscmode.txt>
+
+=head1 BUGS
+
+This document is a work in progress and contains items which require
+further documentation and which are generally incomplete (marked with
+XXX). However all options are included here whether or not they are
+fully documented.
+
+Patches to improve incomplete items (or any other item) would be
+greatfully received on the xen-devel@lists.xensource.com mailing
+list. Please see L<http://wiki.xen.org/wiki/SubmittingXenPatches> for
+information on how to submit a patch to Xen.
+
diff -r f3fc909a083d -r c88ff1ac2417 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1 Thu Nov 17 14:34:11 2011 +0000
+++ b/docs/man/xl.pod.1 Thu Nov 17 14:35:24 2011 +0000
@@ -54,7 +54,7 @@ previously, most commands take I<domain-
=item B<create> [I<OPTIONS>] I<configfile>
-The create subcommand requires a config file: see L<xldomain.cfg> for
+The create subcommand requires a config file: see L<xl.cfg(5)> for
full details of that file format and possible options.
I<configfile> can either be an absolute path to a file, or a relative
@@ -232,7 +232,7 @@ FIXME: Why would you ever see this state
The domain has crashed, which is always a violent ending. Usually
this state can only occur if the domain has been configured not to
-restart on crash. See L<xldomain.cfg> for more info.
+restart on crash. See L<xl.cfg(5)> for more info.
=item B<d - dying>
@@ -319,8 +319,8 @@ executed the reboot action, which may be
domain actually reboots.
The behavior of what happens to a domain when it reboots is set by the
-B<on_reboot> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_reboot> parameter of the domain configuration file when the
+domain was created.
=item B<restore> [I<OPTIONS>] [I<ConfigFile>]
I<CheckpointFile>
@@ -372,8 +372,8 @@ services must be shutdown in the domain.
immediately after signally the domain unless that B<-w> flag is used.
The behavior of what happens to a domain when it reboots is set by the
-B<on_shutdown> parameter of the xldomain.cfg file when the domain was
-created.
+B<on_shutdown> parameter of the domain configuration file when the
+domain was created.
B<OPTIONS>
@@ -699,7 +699,7 @@ The domain id of the guest domain that t
=item I<disc-spec-component>
A disc specification in the same format used for the B<disk> variable in
-the domain config file. See L<xldomain.cfg>.
+the domain config file. See F<xl-disk-configuration>.
=back
@@ -733,9 +733,9 @@ How the device should be presented to th
=item I<be-dev>
-the device in the backend domain (usually domain 0) to be exported; it can be a
-path to a file (file://path/to/file.iso). See B<disk> in
L<xldomain.cfg> for the
-details.
+the device in the backend domain (usually domain 0) to be exported; it
+can be a path to a file (file://path/to/file.iso). See B<disk> in
+L<xl.cfg(5)> for the details.
=back
@@ -754,7 +754,7 @@ I<VirtualDevice> is the cdrom device in
Creates a new network device in the domain specified by I<domain-id>.
I<network-device> describes the device to attach, using the same format
as the
-B<vif> string in the domain config file. See L<xldomain.cfg> for
the
+B<vif> string in the domain config file. See L<xl.cfg(5)> for the
description.
=item B<network-detach> I<domain-id> I<devid|mac>
@@ -795,7 +795,7 @@ List pass-through pci devices for a doma
=head1 SEE ALSO
-B<xldomain.cfg>(5), B<xlcpupool.cfg>(5), B<xentop>(1)
+L<xl.cfg(5)>, L<xlcpupool.cfg(5)>, B<xentop(1)>
=head1 AUTHOR
diff -r f3fc909a083d -r c88ff1ac2417 tools/examples/xlexample.hvm
--- a/tools/examples/xlexample.hvm Thu Nov 17 14:34:11 2011 +0000
+++ b/tools/examples/xlexample.hvm Thu Nov 17 14:35:24 2011 +0000
@@ -3,7 +3,7 @@
# ==================================================================== #
# This is a fairly minimal example of what is required for an
-# HVM guest. For a more complete guide see <XXX Document TBD>
+# HVM guest. For a more complete guide see xl.cfg(5)
# This configures an HVM rather than PV guest
builder = "hvm"
diff -r f3fc909a083d -r c88ff1ac2417 tools/examples/xlexample.pvlinux
--- a/tools/examples/xlexample.pvlinux Thu Nov 17 14:34:11 2011 +0000
+++ b/tools/examples/xlexample.pvlinux Thu Nov 17 14:35:24 2011 +0000
@@ -3,7 +3,7 @@
# ==================================================================== #
# This is a fairly minimal example of what is required for a
-# Paravirtualised Linux guest. For a more complete guide see <XXX Document
TBD>
+# Paravirtualised Linux guest. For a more complete guide see xl.cfg(5)
# Guest name
name = "example.pvlinux"
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 06 of 17] xl: the name field in a guest config file is mandatory
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540536 0
# Node ID 22264859117b883d37b563ddad14515d80568a4e
# Parent c88ff1ac24170a7d2a3c8824735ef9311eb95fe0
xl: the name field in a guest config file is mandatory
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r c88ff1ac2417 -r 22264859117b tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c Thu Nov 17 14:35:24 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c Thu Nov 17 14:35:36 2011 +0000
@@ -575,8 +575,10 @@ static void parse_config_data(const char
if (!xlu_cfg_get_long (config, "hap", &l))
c_info->hap = l;
- if (xlu_cfg_replace_string (config, "name",
&c_info->name))
- c_info->name = strdup("test");
+ if (xlu_cfg_replace_string (config, "name",
&c_info->name)) {
+ fprintf(stderr, "Domain name must be specified.");
+ exit(1);
+ }
if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final filename
# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1321540536 0 # Node ID f1464f6fba419acc019c824cea4aefb97b2360f6 # Parent 22264859117b883d37b563ddad14515d80568a4e docs: generate docs direct into final filename Nothing depends on the final document so there is not much point in generating to a tempfile and move-if-changed. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 22264859117b -r f1464f6fba41 docs/Makefile --- a/docs/Makefile Thu Nov 17 14:35:36 2011 +0000 +++ b/docs/Makefile Thu Nov 17 14:35:36 2011 +0000 @@ -132,37 +132,30 @@ html/%.html: %.markdown @$(INSTALL_DIR) $(@D) @set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \ echo "Running markdown to generate $*.html ... "; \ - $(MARKDOWN) $< > $@.tmp ; \ - $(call move-if-changed,$@.tmp,$@) ; else \ + $(MARKDOWN) $< > $@ ; else \ echo "markdown not installed; skipping $*.html."; fi html/man/%.1.html: man/%.pod.1 Makefile $(INSTALL_DIR) $(@D) - $(POD2HTML) --infile=$< --outfile=$@.tmp - $(call move-if-changed,$@.tmp,$@) + $(POD2HTML) --infile=$< --outfile=$@ html/man/%.5.html: man/%.pod.5 Makefile $(INSTALL_DIR) $(@D) - $(POD2HTML) --infile=$< --outfile=$@.tmp - $(call move-if-changed,$@.tmp,$@) + $(POD2HTML) --infile=$< --outfile=$@ txt/%.txt: %.txt $(INSTALL_DIR) $(@D) - cp $< $@.tmp - $(call move-if-changed,$@.tmp,$@) + cp $< $@ txt/%.txt: %.markdown $(INSTALL_DIR) $(@D) - cp $< $@.tmp - $(call move-if-changed,$@.tmp,$@) + cp $< $@ txt/man/%.1.txt: man/%.pod.1 Makefile $(INSTALL_DIR) $(@D) - $(POD2TEXT) $< $@.tmp - $(call move-if-changed,$@.tmp,$@) + $(POD2TEXT) $< $@ txt/man/%.5.txt: man/%.pod.5 Makefile $(INSTALL_DIR) $(@D) - $(POD2TEXT) $< $@.tmp - $(call move-if-changed,$@.tmp,$@) + $(POD2TEXT) $< $@ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 08 of 17] xlu: add "dont_warn" to xlu_cfg_*
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540537 0
# Node ID 6911d1235f82e52b0b16eeb505ebf80054e47f40
# Parent f1464f6fba419acc019c824cea4aefb97b2360f6
xlu: add "dont_warn" to xlu_cfg_*
I want it for get_long but we might as well have it everywhere.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r f1464f6fba41 -r 6911d1235f82 tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c Thu Nov 17 14:35:36 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c Thu Nov 17 14:35:37 2011 +0000
@@ -165,17 +165,18 @@ static XLU_ConfigSetting *find(const XLU
}
static int find_atom(const XLU_Config *cfg, const char *n,
- XLU_ConfigSetting **set_r) {
+ XLU_ConfigSetting **set_r, int dont_warn) {
XLU_ConfigSetting *set;
set= find(cfg,n);
if (!set) return ESRCH;
if (set->avalues!=1) {
- fprintf(cfg->report,
- "%s:%d: warning: parameter `%s'' is"
- " a list but should be a single value\n",
- cfg->filename, set->lineno, n);
+ if (!dont_warn)
+ fprintf(cfg->report,
+ "%s:%d: warning: parameter `%s'' is"
+ " a list but should be a single value\n",
+ cfg->filename, set->lineno, n);
return EINVAL;
}
*set_r= set;
@@ -183,49 +184,51 @@ static int find_atom(const XLU_Config *c
}
int xlu_cfg_get_string(const XLU_Config *cfg, const char *n,
- const char **value_r) {
+ const char **value_r, int dont_warn) {
XLU_ConfigSetting *set;
int e;
- e= find_atom(cfg,n,&set); if (e) return e;
+ e= find_atom(cfg,n,&set,dont_warn); if (e) return e;
*value_r= set->values[0];
return 0;
}
int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
- char **value_r) {
+ char **value_r, int dont_warn) {
XLU_ConfigSetting *set;
int e;
- e= find_atom(cfg,n,&set); if (e) return e;
+ e= find_atom(cfg,n,&set,dont_warn); if (e) return e;
free(*value_r);
*value_r= strdup(set->values[0]);
return 0;
}
int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
- long *value_r) {
+ long *value_r, int dont_warn) {
long l;
XLU_ConfigSetting *set;
int e;
char *ep;
- e= find_atom(cfg,n,&set); if (e) return e;
+ e= find_atom(cfg,n,&set,dont_warn); if (e) return e;
errno= 0; l= strtol(set->values[0], &ep, 0);
e= errno;
if (errno) {
e= errno;
assert(e==EINVAL || e==ERANGE);
- fprintf(cfg->report,
- "%s:%d: warning: parameter `%s'' could not be
parsed"
- " as a number: %s\n",
- cfg->filename, set->lineno, n, strerror(e));
+ if (!dont_warn)
+ fprintf(cfg->report,
+ "%s:%d: warning: parameter `%s'' could not be
parsed"
+ " as a number: %s\n",
+ cfg->filename, set->lineno, n, strerror(e));
return e;
}
if (*ep || ep==set->values[0]) {
- fprintf(cfg->report,
- "%s:%d: warning: parameter `%s'' is not a valid
number\n",
- cfg->filename, set->lineno, n);
+ if (!dont_warn)
+ fprintf(cfg->report,
+ "%s:%d: warning: parameter `%s'' is not a
valid number\n",
+ cfg->filename, set->lineno, n);
return EINVAL;
}
*value_r= l;
diff -r f1464f6fba41 -r 6911d1235f82 tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h Thu Nov 17 14:35:36 2011 +0000
+++ b/tools/libxl/libxlutil.h Thu Nov 17 14:35:37 2011 +0000
@@ -41,13 +41,17 @@ void xlu_cfg_destroy(XLU_Config*);
* Return values are:
* 0 OK
* ESRCH not defined
- * EINVAL value found but wrong format for request (prints warning)
+ * EINVAL value found but wrong format for request (prints warning unless
dont_warn=true)
* ERANGE value out of range (from strtol)
*/
-int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r);
-int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n, char
**value_r); /* free/strdup version */
-int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r);
+int xlu_cfg_get_string(const XLU_Config*, const char *n, const char **value_r,
+ int dont_warn);
+/* free/strdup version */
+int xlu_cfg_replace_string(const XLU_Config *cfg, const char *n,
+ char **value_r, int dont_warn);
+int xlu_cfg_get_long(const XLU_Config*, const char *n, long *value_r,
+ int dont_warn);
int xlu_cfg_get_list(const XLU_Config*, const char *n,
XLU_ConfigList **list_r /* may be 0 */,
diff -r f1464f6fba41 -r 6911d1235f82 tools/libxl/xl.c
--- a/tools/libxl/xl.c Thu Nov 17 14:35:36 2011 +0000
+++ b/tools/libxl/xl.c Thu Nov 17 14:35:37 2011 +0000
@@ -62,10 +62,10 @@ static void parse_global_config(const ch
exit(1);
}
- if (!xlu_cfg_get_long (config, "autoballoon", &l))
+ if (!xlu_cfg_get_long (config, "autoballoon", &l, 0))
autoballoon = l;
- if (!xlu_cfg_get_string (config, "lockfile", &buf))
+ if (!xlu_cfg_get_string (config, "lockfile", &buf, 0))
lockfile = strdup(buf);
else {
e = asprintf(&lockfile, "%s/xl", (char
*)libxl_lock_dir_path());
@@ -75,7 +75,7 @@ static void parse_global_config(const ch
}
}
- if (!xlu_cfg_get_string (config, "vifscript", &buf))
+ if (!xlu_cfg_get_string (config, "vifscript", &buf, 0))
default_vifscript = strdup(buf);
xlu_cfg_destroy(config);
diff -r f1464f6fba41 -r 6911d1235f82 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c Thu Nov 17 14:35:36 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c Thu Nov 17 14:35:37 2011 +0000
@@ -554,7 +554,7 @@ static void parse_config_data(const char
if (libxl_init_create_info(ctx, c_info))
exit(1);
- if (!xlu_cfg_get_string (config, "seclabel", &buf)) {
+ if (!xlu_cfg_get_string (config, "seclabel", &buf, 0)) {
e = libxl_flask_context_to_sid(ctx, (char *)buf, strlen(buf),
&c_info->ssidref);
if (e) {
@@ -568,19 +568,19 @@ static void parse_config_data(const char
}
c_info->type = LIBXL_DOMAIN_TYPE_PV;
- if (!xlu_cfg_get_string (config, "builder", &buf) &&
+ if (!xlu_cfg_get_string (config, "builder", &buf, 0)
&&
!strncmp(buf, "hvm", strlen(buf)))
c_info->type = LIBXL_DOMAIN_TYPE_HVM;
- if (!xlu_cfg_get_long (config, "hap", &l))
+ if (!xlu_cfg_get_long (config, "hap", &l, 0))
c_info->hap = l;
- if (xlu_cfg_replace_string (config, "name",
&c_info->name)) {
+ if (xlu_cfg_replace_string (config, "name", &c_info->name,
0)) {
fprintf(stderr, "Domain name must be specified.");
exit(1);
}
- if (!xlu_cfg_get_string (config, "uuid", &buf) ) {
+ if (!xlu_cfg_get_string (config, "uuid", &buf, 0) ) {
if ( libxl_uuid_from_string(&c_info->uuid, buf) ) {
fprintf(stderr, "Failed to parse UUID: %s\n", buf);
exit(1);
@@ -589,10 +589,10 @@ static void parse_config_data(const char
libxl_uuid_generate(&c_info->uuid);
}
- if (!xlu_cfg_get_long(config, "oos", &l))
+ if (!xlu_cfg_get_long(config, "oos", &l, 0))
c_info->oos = l;
- if (!xlu_cfg_get_string (config, "pool", &buf)) {
+ if (!xlu_cfg_get_string (config, "pool", &buf, 0)) {
c_info->poolid = -1;
cpupool_qualifier_to_cpupoolid(buf, &c_info->poolid, NULL);
}
@@ -606,37 +606,37 @@ static void parse_config_data(const char
exit(1);
/* the following is the actual config parsing with overriding values in the
structures */
- if (!xlu_cfg_get_long (config, "vcpus", &l)) {
+ if (!xlu_cfg_get_long (config, "vcpus", &l, 0)) {
b_info->max_vcpus = l;
b_info->cur_vcpus = (1 << l) - 1;
}
- if (!xlu_cfg_get_long (config, "maxvcpus", &l))
+ if (!xlu_cfg_get_long (config, "maxvcpus", &l, 0))
b_info->max_vcpus = l;
- if (!xlu_cfg_get_long (config, "memory", &l)) {
+ if (!xlu_cfg_get_long (config, "memory", &l, 0)) {
b_info->max_memkb = l * 1024;
b_info->target_memkb = b_info->max_memkb;
}
- if (!xlu_cfg_get_long (config, "maxmem", &l))
+ if (!xlu_cfg_get_long (config, "maxmem", &l, 0))
b_info->max_memkb = l * 1024;
- if (xlu_cfg_get_string (config, "on_poweroff", &buf))
+ if (xlu_cfg_get_string (config, "on_poweroff", &buf, 0))
buf = "destroy";
if (!parse_action_on_shutdown(buf, &d_config->on_poweroff)) {
fprintf(stderr, "Unknown on_poweroff action \"%s\"
specified\n", buf);
exit(1);
}
- if (xlu_cfg_get_string (config, "on_reboot", &buf))
+ if (xlu_cfg_get_string (config, "on_reboot", &buf, 0))
buf = "restart";
if (!parse_action_on_shutdown(buf, &d_config->on_reboot)) {
fprintf(stderr, "Unknown on_reboot action \"%s\"
specified\n", buf);
exit(1);
}
- if (xlu_cfg_get_string (config, "on_watchdog", &buf))
+ if (xlu_cfg_get_string (config, "on_watchdog", &buf, 0))
buf = "destroy";
if (!parse_action_on_shutdown(buf, &d_config->on_watchdog)) {
fprintf(stderr, "Unknown on_watchdog action \"%s\"
specified\n", buf);
@@ -644,7 +644,7 @@ static void parse_config_data(const char
}
- if (xlu_cfg_get_string (config, "on_crash", &buf))
+ if (xlu_cfg_get_string (config, "on_crash", &buf, 0))
buf = "destroy";
if (!parse_action_on_shutdown(buf, &d_config->on_crash)) {
fprintf(stderr, "Unknown on_crash action \"%s\"
specified\n", buf);
@@ -654,48 +654,48 @@ static void parse_config_data(const char
/* libxl_get_required_shadow_memory() must be called after final values
* (default or specified) for vcpus and memory are set, because the
* calculation depends on those values. */
- b_info->shadow_memkb = !xlu_cfg_get_long(config,
"shadow_memory", &l)
+ b_info->shadow_memkb = !xlu_cfg_get_long(config,
"shadow_memory", &l, 0)
? l * 1024
: libxl_get_required_shadow_memory(b_info->max_memkb,
b_info->max_vcpus);
- if (!xlu_cfg_get_long (config, "nomigrate", &l))
+ if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
b_info->disable_migrate = l;
- if (!xlu_cfg_get_long(config, "tsc_mode", &l))
+ if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
b_info->tsc_mode = l;
- if (!xlu_cfg_get_long (config, "videoram", &l))
+ if (!xlu_cfg_get_long (config, "videoram", &l, 0))
b_info->video_memkb = l * 1024;
- if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+ if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
dm_info->gfx_passthru = l;
switch(c_info->type) {
case LIBXL_DOMAIN_TYPE_HVM:
- if (!xlu_cfg_get_string (config, "kernel", &buf))
+ if (!xlu_cfg_get_string (config, "kernel", &buf, 0))
fprintf(stderr, "WARNING: ignoring \"kernel\"
directive for HVM guest. "
"Use \"firmware_override\" instead if you
really want a non-default firmware\n");
xlu_cfg_replace_string (config, "firmware_override",
- &b_info->u.hvm.firmware);
- if (!xlu_cfg_get_long (config, "pae", &l))
+ &b_info->u.hvm.firmware, 0);
+ if (!xlu_cfg_get_long (config, "pae", &l, 0))
b_info->u.hvm.pae = l;
- if (!xlu_cfg_get_long (config, "apic", &l))
+ if (!xlu_cfg_get_long (config, "apic", &l, 0))
b_info->u.hvm.apic = l;
- if (!xlu_cfg_get_long (config, "acpi", &l))
+ if (!xlu_cfg_get_long (config, "acpi", &l, 0))
b_info->u.hvm.acpi = l;
- if (!xlu_cfg_get_long (config, "nx", &l))
+ if (!xlu_cfg_get_long (config, "nx", &l, 0))
b_info->u.hvm.nx = l;
- if (!xlu_cfg_get_long (config, "viridian", &l))
+ if (!xlu_cfg_get_long (config, "viridian", &l, 0))
b_info->u.hvm.viridian = l;
- if (!xlu_cfg_get_long (config, "hpet", &l))
+ if (!xlu_cfg_get_long (config, "hpet", &l, 0))
b_info->u.hvm.hpet = l;
- if (!xlu_cfg_get_long (config, "vpt_align", &l))
+ if (!xlu_cfg_get_long (config, "vpt_align", &l, 0))
b_info->u.hvm.vpt_align = l;
- if (!xlu_cfg_get_long (config, "timer_mode", &l))
+ if (!xlu_cfg_get_long (config, "timer_mode", &l, 0))
b_info->u.hvm.timer_mode = l;
- if (!xlu_cfg_get_long (config, "nestedhvm", &l))
+ if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0))
b_info->u.hvm.nested_hvm = l;
break;
case LIBXL_DOMAIN_TYPE_PV:
@@ -703,12 +703,12 @@ static void parse_config_data(const char
char *cmdline = NULL;
const char *root = NULL, *extra = "";
- xlu_cfg_replace_string (config, "kernel",
&b_info->u.pv.kernel.path);
-
- xlu_cfg_replace_string (config, "kernel",
&b_info->u.pv.kernel.path);
-
- xlu_cfg_get_string (config, "root", &root);
- xlu_cfg_get_string (config, "extra", &extra);
+ xlu_cfg_replace_string (config, "kernel",
&b_info->u.pv.kernel.path, 0);
+
+ xlu_cfg_replace_string (config, "kernel",
&b_info->u.pv.kernel.path, 0);
+
+ xlu_cfg_get_string (config, "root", &root, 0);
+ xlu_cfg_get_string (config, "extra", &extra, 0);
if (root) {
if (asprintf(&cmdline, "root=%s %s", root, extra) ==
-1)
@@ -722,8 +722,10 @@ static void parse_config_data(const char
exit(1);
}
- xlu_cfg_replace_string (config, "bootloader",
&b_info->u.pv.bootloader);
- xlu_cfg_replace_string (config, "bootloader_args",
&b_info->u.pv.bootloader_args);
+ xlu_cfg_replace_string (config, "bootloader",
+ &b_info->u.pv.bootloader, 0);
+ xlu_cfg_replace_string (config, "bootloader_args",
+ &b_info->u.pv.bootloader_args, 0);
if (!b_info->u.pv.bootloader &&
!b_info->u.pv.kernel.path) {
fprintf(stderr, "Neither kernel nor bootloader
specified\n");
@@ -731,7 +733,7 @@ static void parse_config_data(const char
}
b_info->u.pv.cmdline = cmdline;
- xlu_cfg_replace_string (config, "ramdisk",
&b_info->u.pv.ramdisk.path);
+ xlu_cfg_replace_string (config, "ramdisk",
&b_info->u.pv.ramdisk.path, 0);
break;
}
default:
@@ -906,15 +908,15 @@ skip_vfb:
}
}
- if (!xlu_cfg_get_long (config, "pci_msitranslate", &l))
+ if (!xlu_cfg_get_long (config, "pci_msitranslate", &l, 0))
pci_msitranslate = l;
- if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l))
+ if (!xlu_cfg_get_long (config, "pci_power_mgmt", &l, 0))
pci_power_mgmt = l;
/* To be reworked (automatically enabled) once the auto ballooning
* after guest starts is done (with PCI devices passed in). */
- if (!xlu_cfg_get_long (config, "e820_host", &l)) {
+ if (!xlu_cfg_get_long (config, "e820_host", &l, 0)) {
switch (c_info->type) {
case LIBXL_DOMAIN_TYPE_HVM:
fprintf(stderr, "Can''t do e820_host in HVM
mode!");
@@ -982,7 +984,7 @@ skip_vfb:
}
break;
case EINVAL: /* config option is not a list, parse as a string */
- if (!xlu_cfg_get_string(config, "cpuid", &buf)) {
+ if (!xlu_cfg_get_string(config, "cpuid", &buf, 0)) {
char *buf2, *p, *strtok_ptr = NULL;
const char *errstr;
@@ -1030,7 +1032,7 @@ skip_vfb:
if (libxl_init_dm_info(ctx, dm_info, c_info, b_info))
exit(1);
/* parse device model arguments, this works for pv, hvm and stubdom */
- if (!xlu_cfg_get_string (config, "device_model", &buf)) {
+ if (!xlu_cfg_get_string (config, "device_model", &buf, 0)) {
fprintf(stderr,
"WARNING: ignoring device_model directive.\n"
"WARNING: Use \"device_model_override\" instead
if you"
@@ -1049,8 +1051,8 @@ skip_vfb:
xlu_cfg_replace_string (config, "device_model_override",
- &dm_info->device_model);
- if (!xlu_cfg_get_string (config, "device_model_version",
&buf)) {
+ &dm_info->device_model, 0);
+ if (!xlu_cfg_get_string (config, "device_model_version",
&buf, 0)) {
if (!strcmp(buf, "qemu-xen-traditional")) {
dm_info->device_model_version
= LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
@@ -1064,7 +1066,7 @@ skip_vfb:
}
} else if (dm_info->device_model)
fprintf(stderr, "WARNING: device model override given without
specific DM version\n");
- if (!xlu_cfg_get_long (config,
"device_model_stubdomain_override", &l))
+ if (!xlu_cfg_get_long (config,
"device_model_stubdomain_override", &l, 0))
dm_info->device_model_stubdomain = l;
#define parse_extra_args(type) \
@@ -1092,46 +1094,46 @@ skip_vfb:
#undef parse_extra_args
if (c_info->type == LIBXL_DOMAIN_TYPE_HVM) {
- if (!xlu_cfg_get_long (config, "stdvga", &l))
+ if (!xlu_cfg_get_long (config, "stdvga", &l, 0))
dm_info->stdvga = l;
- if (!xlu_cfg_get_long (config, "vnc", &l))
+ if (!xlu_cfg_get_long (config, "vnc", &l, 0))
dm_info->vnc = l;
- xlu_cfg_replace_string (config, "vnclisten",
&dm_info->vnclisten);
- xlu_cfg_replace_string (config, "vncpasswd",
&dm_info->vncpasswd);
- if (!xlu_cfg_get_long (config, "vncdisplay", &l))
+ xlu_cfg_replace_string (config, "vnclisten",
&dm_info->vnclisten, 0);
+ xlu_cfg_replace_string (config, "vncpasswd",
&dm_info->vncpasswd, 0);
+ if (!xlu_cfg_get_long (config, "vncdisplay", &l, 0))
dm_info->vncdisplay = l;
- if (!xlu_cfg_get_long (config, "vncunused", &l))
+ if (!xlu_cfg_get_long (config, "vncunused", &l, 0))
dm_info->vncunused = l;
- xlu_cfg_replace_string (config, "keymap",
&dm_info->keymap);
- if (!xlu_cfg_get_long (config, "sdl", &l))
+ xlu_cfg_replace_string (config, "keymap",
&dm_info->keymap, 0);
+ if (!xlu_cfg_get_long (config, "sdl", &l, 0))
dm_info->sdl = l;
- if (!xlu_cfg_get_long (config, "opengl", &l))
+ if (!xlu_cfg_get_long (config, "opengl", &l, 0))
dm_info->opengl = l;
- if (!xlu_cfg_get_long (config, "spice", &l))
+ if (!xlu_cfg_get_long (config, "spice", &l, 0))
dm_info->spice = l;
- if (!xlu_cfg_get_long (config, "spiceport", &l))
+ if (!xlu_cfg_get_long (config, "spiceport", &l, 0))
dm_info->spiceport = l;
- if (!xlu_cfg_get_long (config, "spicetls_port", &l))
+ if (!xlu_cfg_get_long (config, "spicetls_port", &l, 0))
dm_info->spicetls_port = l;
- xlu_cfg_replace_string (config, "spicehost",
&dm_info->spicehost);
- if (!xlu_cfg_get_long (config, "spicedisable_ticketing",
&l))
+ xlu_cfg_replace_string (config, "spicehost",
&dm_info->spicehost, 0);
+ if (!xlu_cfg_get_long (config, "spicedisable_ticketing",
&l, 0))
dm_info->spicedisable_ticketing = l;
- xlu_cfg_replace_string (config, "spicepasswd",
&dm_info->spicepasswd);
- if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l))
+ xlu_cfg_replace_string (config, "spicepasswd",
&dm_info->spicepasswd, 0);
+ if (!xlu_cfg_get_long (config, "spiceagent_mouse", &l,
0))
dm_info->spiceagent_mouse = l;
else
dm_info->spiceagent_mouse = 1;
- if (!xlu_cfg_get_long (config, "nographic", &l))
+ if (!xlu_cfg_get_long (config, "nographic", &l, 0))
dm_info->nographic = l;
- if (!xlu_cfg_get_long (config, "gfx_passthru", &l))
+ if (!xlu_cfg_get_long (config, "gfx_passthru", &l, 0))
dm_info->gfx_passthru = l;
- xlu_cfg_replace_string (config, "serial",
&dm_info->serial);
- xlu_cfg_replace_string (config, "boot",
&dm_info->boot);
- if (!xlu_cfg_get_long (config, "usb", &l))
+ xlu_cfg_replace_string (config, "serial",
&dm_info->serial, 0);
+ xlu_cfg_replace_string (config, "boot",
&dm_info->boot, 0);
+ if (!xlu_cfg_get_long (config, "usb", &l, 0))
dm_info->usb = l;
- xlu_cfg_replace_string (config, "usbdevice",
&dm_info->usbdevice);
- xlu_cfg_replace_string (config, "soundhw",
&dm_info->soundhw);
- if (!xlu_cfg_get_long (config, "xen_platform_pci", &l))
+ xlu_cfg_replace_string (config, "usbdevice",
&dm_info->usbdevice, 0);
+ xlu_cfg_replace_string (config, "soundhw",
&dm_info->soundhw, 0);
+ if (!xlu_cfg_get_long (config, "xen_platform_pci", &l,
0))
dm_info->xen_platform_pci = l;
}
@@ -4761,7 +4763,7 @@ int main_cpupoolcreate(int argc, char **
return -ERROR_FAIL;
}
- if (!xlu_cfg_get_string (config, "name", &buf))
+ if (!xlu_cfg_get_string (config, "name", &buf, 0))
name = strdup(buf);
else
name = libxl_basename(filename);
@@ -4770,7 +4772,7 @@ int main_cpupoolcreate(int argc, char **
return -ERROR_FAIL;
}
- if (!xlu_cfg_get_string (config, "sched", &buf)) {
+ if (!xlu_cfg_get_string (config, "sched", &buf, 0)) {
if ((schedid = libxl_name_to_schedid(ctx, buf)) < 0) {
fprintf(stderr, "Unknown scheduler\n");
return -ERROR_FAIL;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 09 of 17] libxl: use named options for tsc_mode
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321540537 0
# Node ID c4571d33f5829bac2e1da169f9d1398810c0b7d2
# Parent 6911d1235f82e52b0b16eeb505ebf80054e47f40
libxl: use named options for tsc_mode.
Add an enum at the libxl level with a hopefully descriptive set of names.
Deprecate the use of an integer in xl cfg files.
Signed-off-by: Ian Campbell
diff -r 6911d1235f82 -r c4571d33f582 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5 Thu Nov 17 14:35:37 2011 +0000
+++ b/docs/man/xl.cfg.pod.5 Thu Nov 17 14:35:37 2011 +0000
@@ -491,11 +491,45 @@ compatibility mode on more modern Window
=item B<tsc_mode="MODE">
+
Specifies how the TSC (Time Stamp Counter) should be provided to the
-guest. XXX ???
+guest (X86 only). Specifying this option as a number is
+deprecated. Options are:
+
+=over 4
+
+=item B<"default">
+
+Guest rdtsc/p executed natively when monotonicity can be guaranteed
+and emulated otherwise (with frequency scaled if necessary).
+
+=item B<"always_emulate">
+
+Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p
+always emulated and the virtual TSC will appear to increment (kernel
+and user) at a fixed 1GHz rate, regardless of the PCPU HZ rate or
+power state; Although there is an overhead associated with emulation
+this will NOT affect underlying CPU performance.
+
+=item B<"native">
+
+Guest rdtsc always executed natively (no monotonicity/frequency
+guarantees); guest rdtscp emulated at native frequency if unsupported
+by h/w, else executed natively.
+
+=item B<"native_paravirt">
+
+Same as B<native>, except xen manages TSC_AUX register so guest can
+determine when a restore/migration has occurred and assumes guest
+obtains/uses pvclock-like mechanism to adjust for monotonicity and
+frequency changes.
=back
+=back
+
+Please see F<docs/misc/tscmode.txt> for more information on this option.
+
=head3 Support for Paravirtualisation of HVM Guests
The following options allow Paravirtualised features (such as devices)
diff -r 6911d1235f82 -r c4571d33f582 tools/libxl/libxl_dom.c
--- a/tools/libxl/libxl_dom.c Thu Nov 17 14:35:37 2011 +0000
+++ b/tools/libxl/libxl_dom.c Thu Nov 17 14:35:37 2011 +0000
@@ -73,12 +73,29 @@ int libxl__build_pre(libxl__gc *gc, uint
libxl_domain_build_info *info, libxl__domain_build_state *state)
{
libxl_ctx *ctx = libxl__gc_owner(gc);
+ int tsc_mode;
xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus);
xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
LIBXL_MAXMEM_CONSTANT);
if (info->type == LIBXL_DOMAIN_TYPE_PV)
xc_domain_set_memmap_limit(ctx->xch, domid,
(info->max_memkb + info->u.pv.slack_memkb));
- xc_domain_set_tsc_info(ctx->xch, domid, info->tsc_mode, 0, 0, 0);
+ switch (info->tsc_mode) {
+ case LIBXL_TSC_MODE_DEFAULT:
+ tsc_mode = 0;
+ break;
+ case LIBXL_TSC_MODE_ALWAYS_EMULATE:
+ tsc_mode = 1;
+ break;
+ case LIBXL_TSC_MODE_NATIVE:
+ tsc_mode = 2;
+ break;
+ case LIBXL_TSC_MODE_NATIVE_PARAVIRT:
+ tsc_mode = 3;
+ break;
+ default:
+ abort();
+ }
+ xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
if ( info->disable_migrate )
xc_domain_disable_migrate(ctx->xch, domid);
diff -r 6911d1235f82 -r c4571d33f582 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl Thu Nov 17 14:35:37 2011 +0000
+++ b/tools/libxl/libxl_types.idl Thu Nov 17 14:35:37 2011 +0000
@@ -85,6 +85,13 @@ libxl_button = Enumeration("button", [
(2, "SLEEP"),
])
+libxl_tsc_mode = Enumeration("tsc_mode", [
+ (0, "default"),
+ (1, "always_emulate"),
+ (2, "native"),
+ (3, "native_paravirt"),
+ ])
+
#
# Complex libxl types
#
@@ -154,7 +161,7 @@ libxl_domain_create_info = Struct("domai
libxl_domain_build_info = Struct("domain_build_info",[
("max_vcpus", integer),
("cur_vcpus", integer),
- ("tsc_mode", integer),
+ ("tsc_mode", libxl_tsc_mode),
("max_memkb", uint32),
("target_memkb", uint32),
("video_memkb", uint32),
diff -r 6911d1235f82 -r c4571d33f582 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c Thu Nov 17 14:35:37 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c Thu Nov 17 14:35:37 2011 +0000
@@ -328,7 +328,7 @@ static void printf_info(int domid,
printf("\t(build_info)\n");
printf("\t(max_vcpus %d)\n", b_info->max_vcpus);
- printf("\t(tsc_mode %d)\n", b_info->tsc_mode);
+ printf("\t(tsc_mode %s)\n",
libxl_tsc_mode_to_string(b_info->tsc_mode));
printf("\t(max_memkb %d)\n", b_info->max_memkb);
printf("\t(target_memkb %d)\n", b_info->target_memkb);
printf("\t(nomigrate %d)\n", b_info->disable_migrate);
@@ -662,8 +662,28 @@ static void parse_config_data(const char
if (!xlu_cfg_get_long (config, "nomigrate", &l, 0))
b_info->disable_migrate = l;
- if (!xlu_cfg_get_long(config, "tsc_mode", &l, 0))
+ if (!xlu_cfg_get_long(config, "tsc_mode", &l, 1)) {
+ const char *s = libxl_tsc_mode_to_string(l);
+ fprintf(stderr, "WARNING: specifying \"tsc_mode\" as an
integer is deprecated. "
+ "Please use the named parameter variant. %s%s%s\n",
+ s ? "e.g. tsc_mode=\"" : "",
+ s ? s : "",
+ s ? "\"" : "");
+
+ if (l < LIBXL_TSC_MODE_DEFAULT ||
+ l > LIBXL_TSC_MODE_NATIVE_PARAVIRT) {
+ fprintf(stderr, "ERROR: invalid value %ld for
\"tsc_mode\"\n", l);
+ exit (1);
+ }
b_info->tsc_mode = l;
+ } else if (!xlu_cfg_get_string(config, "tsc_mode", &buf, 0))
{
+ fprintf(stderr, "got a tsc mode string: \"%s\"\n",
buf);
+ if (libxl_tsc_mode_from_string(buf, &b_info->tsc_mode)) {
+ fprintf(stderr, "ERROR: invalid value \"%s\" for
\"tsc_mode\"\n",
+ buf);
+ exit (1);
+ }
+ }
if (!xlu_cfg_get_long (config, "videoram", &l, 0))
b_info->video_memkb = l * 1024;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 10 of 17] docs: remove non-breaking spaces from sedf_scheduler_mini-HOWTO.txt
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321541652 0
# Node ID 617f5d6e9e69b4f6362df91f078b7dc2abdbd80a
# Parent c4571d33f5829bac2e1da169f9d1398810c0b7d2
docs: remove non-breaking spaces from sedf_scheduler_mini-HOWTO.txt
This document contains several 0xa0 characters (non-breaking spaces). These do
not display correctly in (some) terminals or when the document is rendered by
(some)
browsers. Re-encode them as spaces.
I''m not confident that this change will make it through being encoded
as a patch
and sent through email. Its effect can be replicated with:
perl -i -p -e ''s/\xa0/ /g''
docs/misc/sedf_scheduler_mini-HOWTO.txt
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r c4571d33f582 -r 617f5d6e9e69 docs/misc/sedf_scheduler_mini-HOWTO.txt
--- a/docs/misc/sedf_scheduler_mini-HOWTO.txt Thu Nov 17 14:35:37 2011 +0000
+++ b/docs/misc/sedf_scheduler_mini-HOWTO.txt Thu Nov 17 14:54:12 2011 +0000
@@ -8,37 +8,37 @@ Overview:
uses realtime-algorithms to ensure time guarantees.
Usage:
- -add "sched=sedf" on Xen''s boot command-line
- -create domains as usual
- -use "xm sched-sedf <dom-id> <period> <slice>
<latency-hint> <extra> <weight>"
- Where:
- -period/slice are the normal EDF scheduling parameters in nanosecs
- -latency-hint is the scaled period in case the domain is doing heavy I/O
+ -add "sched=sedf" on Xen''s boot command-line
+ -create domains as usual
+ -use "xm sched-sedf <dom-id> <period> <slice>
<latency-hint> <extra> <weight>"
+ Where:
+ -period/slice are the normal EDF scheduling parameters in nanosecs
+ -latency-hint is the scaled period in case the domain is doing heavy I/O
(unused by the currently compiled version)
- -extra is a flag (0/1), which controls whether the domain can run in
+ -extra is a flag (0/1), which controls whether the domain can run in
extra-time
- -weight is mutually exclusive with period/slice and specifies another
+ -weight is mutually exclusive with period/slice and specifies another
way of setting a domains cpu slice
Examples:
-normal EDF (20ms/5ms):
- xm sched-sedf <dom-id> 20000000 5000000 0 0 0
+ normal EDF (20ms/5ms):
+ xm sched-sedf <dom-id> 20000000 5000000 0 0 0
-best-effort domains (i.e. non-realtime):
- xm sched-sedf <dom-id> 20000000 0 0 1 0
-
+ best-effort domains (i.e. non-realtime):
+ xm sched-sedf <dom-id> 20000000 0 0 1 0
+
normal EDF (20ms/5ms) + share of extra-time:
- xm sched-sedf <dom-id> 20000000 5000000 0 1 0
+ xm sched-sedf <dom-id> 20000000 5000000 0 1 0
-4 domains with weights 2:3:4:2
- xm sched-sedf <d1> 0 0 0 0 2
- xm sched-sedf <d2> 0 0 0 0 3
- xm sched-sedf <d3> 0 0 0 0 4
- xm sched-sedf <d4> 0 0 0 0 2
+ 4 domains with weights 2:3:4:2
+ xm sched-sedf <d1> 0 0 0 0 2
+ xm sched-sedf <d2> 0 0 0 0 3
+ xm sched-sedf <d3> 0 0 0 0 4
+ xm sched-sedf <d4> 0 0 0 0 2
-1 fully-specified (10ms/3ms) domain, 3 other domains share
-available rest in 2:7:3 ratio:
- xm sched-sedf <d1> 10000000 3000000 0 0 0
- xm sched-sedf <d2> 0 0 0 0 2
- xm sched-sedf <d3> 0 0 0 0 7
- xm sched-sedf <d4> 0 0 0 0 3
+ 1 fully-specified (10ms/3ms) domain, 3 other domains share
+ available rest in 2:7:3 ratio:
+ xm sched-sedf <d1> 10000000 3000000 0 0 0
+ xm sched-sedf <d2> 0 0 0 0 2
+ xm sched-sedf <d3> 0 0 0 0 7
+ xm sched-sedf <d4> 0 0 0 0 3
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 11 of 17] docs: remove some fatally out of date documentation
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321541678 0
# Node ID 55ce23cb7b2af3c497b3a10658e09d5fc11eb45f
# Parent 617f5d6e9e69b4f6362df91f078b7dc2abdbd80a
docs: remove some fatally out of date documentation
I think these are better off deleted than remaining to confuse people.
docs/misc/blkif-drivers-explained.txt:
- Talks about Xen 2.0 beta, talks about the old pre-xenstored IPC mechanism.
docs/misc/cpuid-config-for-guest.txt:
- Doesn''t really say anything, in particular doesn''t actually
describe how to
configure CPUID.
docs/misc/hg-cheatsheet.txt:
- Not out of date per-se wrt mercural but talk about Xen 2.0 and gives URLs
under www.cl.cam.ac.uk. Talks a lot about bitkeeper. Given that mercurial is
hardly unusual anymore I think there must be better guides out there so this
one is not worth resurecting.
docs/misc/network_setup.txt:
- This is more comprehensively documented on the wiki these days.
docs/misc/VMX_changes.txt:
- Is basically a changelog from the initial implementation of VMX in 2004.
I''m not sure about some of the other docs, but these ones seemed fairly
obvious.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/VMX_changes.txt
--- a/docs/misc/VMX_changes.txt Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,90 +0,0 @@
-Changes to Xen in support of Intel(R) Vanderpool Technology
--------------------------------------------------------------
-
-Our VT extensions to the Xen hypervisor provide full platform
-virtualization, including CPU(s), memory, and I/O infrastructure. The
-generic code in Xen handles and schedules those virtual machines as it
-does for the existing para-virtualized domains.
-
-Full virtualization required by the OS guests requires full device
-virtualization as well. The device models in BOCHS
-(http://bochs.sourceforge.net/) were decoupled from the CPU
-virtualization, and are used to virtualize the legacy devices (such as
-keyboard, mouse, VGA, IDE) in the PC platform. At this point, the
-device models run in user mode on domain 0, not in the Xen hypervisor.
-
-We would like to thank Ian Pratt and Keir Fraser for reviewing our
-design and code intensively, and for providing numerous useful
-suggestions to improve the architecture and code.
-
-We have a list of Intel team members who take credit for making this
-release happen: Yunhong Jiang, Nitin Kamble, Chengyuan Li, Xin Li,
-Xiaofeng Ling, Benjamin Liu, Asit Mallick, Jun Nakajima, Sunil Saxena,
-Arun Sharma, Edwin Zhai, Jeff Zheng, and Louis Zhuang. We''ll continue
-to add more features to complete full virtualization in Xen using VT.
-
-The notes document the changes to the Xen hypervisor in order to add
-VT support. The changes to other areas, such as Control Panel will be
-added as we deliver the code.
-
-Summary of changes for the first release
-----------------------------------------
-December 15, 2004
-
- * VT specific event handling and domain management were added.
-
- * Shadow mode was extended to support full 32-bit guests
-
- * Domain switching code was extended to support VT domain
-
- * I/O request handling was added to communicate with the device model
-
- * Domain builder was extended to provide the environment when the
- guest enters the protected mode, including E820 memory and VGA
- info, typically obtained by BIOS calls.
-
-New code:
----------
- VT (Vanderpool Technology) is based on the new VMX (Virtual
- Machine Extensions) architecture. The current release of the
- software supports 32-bit only.
-
- * arch/x86/vmx.[ch] and arch/x86/vmx_*.[ch]: created to handle
- VMX-specific events in order to provide virtual machine.
-
- * arch/x86/x86_32/entry.S: new code path was added to have the
- first-level handler from VM exits. The first-level handler calls
- the second-level handler in arch/x86/vmx.c.
-
- * arch/x86/setup.c: new function start_vmx() to init_intel() to
- enable VMX mode.
-
- * include/asm-x86/config.h: #ifdef CONFIG_VMX was added.
-
- * arch/x86/domain.c: new code patch was added to create a VMX
- domain given the flag from the control panel.
-
- * include/public/io/ioreq.h: A new data structure was added to
- define the I/O requests between the Xen hypervisor and the
- device models.
-
-Changes to the existing code:
------------------------------
-
- * arch/x86/shadow.[ch]: new mode SHM_full_32 was added to support
- full virtualization. The current Xen code assumes that the guest
- page directory and tables have _machine_ (or host) physical page
- frame numbers, and the new code allows to support _guest_
- physical page frame numbers
-
- * include/asm-x86/processor.h: struct arch_vmx_struct arch_vmx has
- been added to the thread_struct data structure. The arch_vmx has
- the additional VMX-related CPU context.
-
- * arch/x86/io_apic.c: reverse mapping between vector and irq has
- been added. We will revisit this code when considering MSI
- support.
-
---- Jun
-
-
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/blkif-drivers-explained.txt
--- a/docs/misc/blkif-drivers-explained.txt Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,485 +0,0 @@
-=== How the Blkif Drivers Work ==-Andrew Warfield
-andrew.warfield@cl.cam.ac.uk
-
-The intent of this is to explain at a fairly detailed level how the
-split device drivers work in Xen 1.3 (aka 2.0beta). The intended
-audience for this, I suppose, is anyone who intends to work with the
-existing blkif interfaces and wants something to help them get up to
-speed with the code in a hurry. Secondly though, I hope to break out
-the general mechanisms that are used in the drivers that are likely to
-be necessary to implement other drivers interfaces.
-
-As a point of warning before starting, it is worth mentioning that I
-anticipate much of the specifics described here changing in the near
-future. There has been talk about making the blkif protocol
-a bit more efficient than it currently is. Keir''s addition of grant
-tables will change the current remapping code that is used when shared
-pages are initially set up.
-
-Also, writing other control interface types will likely need support
-from Xend, which at the moment has a steep learning curve... this
-should be addressed in the future.
-
-For more information on the driver model as a whole, read the
-"Reconstructing I/O" technical report
-(http://www.cl.cam.ac.uk/Research/SRG/netos/papers/2004-xenngio.pdf).
-
-==== High-level structure of a split-driver interface ===-
-Why would you want to write a split driver in the first place? As Xen
-is a virtual machine manager and focuses on isolation as an initial
-design principle, it is generally considered unwise to share physical
-access to devices across domains. The reasons for this are obvious:
-when device resources are shared, misbehaving code or hardware can
-result in the failure of all of the client applications. Moreover, as
-virtual machines in Xen are entire OSs, standard device drives that
-they might use cannot have multiple instantiations for a single piece
-of hardware. In light of all this, the general approach in Xen is to
-give a single virtual machine hardware access to a device, and where
-other VMs want to share the device, export a higher-level interface to
-facilitate that sharing. If you don''t want to share, that''s
fine.
-There are currently Xen users actively exploring running two
-completely isolated X-Servers on a Xen host, each with it''s own video
-card, keyboard, and mouse. In these situations, the guests need only
-be given physical access to the necessary devices and left to go on
-their own. However, for devices such as disks and network interfaces,
-where sharing is required, the split driver approach is a good
-solution.
-
-The structure is like this:
-
- +--------------------------+ +--------------------------+
- | Domain 0 (privileged) | | Domain 1 (unprivileged) |
- | | | |
- | Xend ( Application ) | | |
- | Blkif Backend Driver | | Blkif Frontend Driver |
- | Physical Device Driver | | |
- +--------------------------+ +--------------------------+
- +--------------------------------------------------------+
- | X E N |
- +--------------------------------------------------------+
-
-
-The Blkif driver is in two parts, which we refer to as frontend (FE)
-and a backend (BE). Together, they serve to proxy device requests
-between the guest operating system in an unprivileged domain, and the
-physical device driver in the physical domain. An additional benefit
-to this approach is that the FE driver can provide a single interface
-for a whole class of physical devices. The blkif interface mounts
-IDE, SCSI, and our own VBD-structured disks, independent of the
-physical driver underneath. Moreover, supporting additional OSs only
-requires that a new FE driver be written to connect to the existing
-backend.
-
-==== Inter-Domain Communication Mechanisms ===-
-===== Event Channels ====-
-Before getting into the specifics of the block interface driver, it is
-worth discussing the mechanisms that are used to communicate between
-domains. Two mechanisms are used to allow the construction of
-high-performance drivers: event channels and shared-memory rings.
-
-Event channels are an asynchronous interdomain notification
-mechanism. Xen allows channels to be instantiated between two
-domains, and domains can request that a virtual irq be attached to
-notifications on a given channel. The result of this is that the
-frontend domain can send a notification on an event channel, resulting
-in an interrupt entry into the backend at a later time.
-
-The event channel between two domains is instantiated in the Xend code
-during driver startup (described later). Xend''s channel.py
-(tools/python/xen/xend/server/channel.py) defines the function
-
-
-def eventChannel(dom1, dom2):
- return xc.evtchn_bind_interdomain(dom1=dom1, dom2=dom2)
-
-
-which maps to xc_evtchn_bind_interdomain() in tools/libxc/xc_evtchn.c,
-which in turn generates a hypercall to Xen to patch the event channel
-between the domains. Only a privileged domain can request the
-creation of an event channel.
-
-Once the event channel is created in Xend, its ends are passed to both the
-front and backend domains over the control channel. The end that is
-passed to a domain is just an integer "port" uniquely identifying the
-event channel''s local connection to that domain. An example of this
-setup code is in linux-2.6.x/drivers/xen/blkfront/blkfront.c in
-blkif_connect(), which receives several status change events as
-the driver starts up. It is passed an event channel end in a
-BLKIF_INTERFACE_STATUS_CONNECTED message, and patches it in like this:
-
-
- blkif_evtchn = status->evtchn;
- blkif_irq = bind_evtchn_to_irq(blkif_evtchn);
- if ( (rc = request_irq(blkif_irq, blkif_int,
- SA_SAMPLE_RANDOM, "blkif", NULL)) )
- printk(KERN_ALERT"blkfront request_irq failed (%ld)\n",rc);
-
-
-This code associates a virtual irq with the event channel, and
-attaches the function blkif_int() as an interrupt handler for that
-irq. blkif_int() simply handles the notification and returns, it does
-not need to interact with the channel at all.
-
-An example of generating a notification can also be seen in blkfront.c:
-
-
-static inline void flush_requests(void)
-{
- DISABLE_SCATTERGATHER();
- wmb(); /* Ensure that the frontend can see the requests. */
- blk_ring->req_prod = req_prod;
- notify_via_evtchn(blkif_evtchn);
-}
-}}}
-
-notify_via_evtchn() issues a hypercall to set the event waiting flag on
-the other domain''s end of the channel.
-
-===== Communication Rings ====-
-Event channels are strictly a notification mechanism between domains.
-To move large chunks of data back and forth, Xen allows domains to
-share pages of memory. We use communication rings as a means of
-managing access to a shared memory page for message passing between
-domains. These rings are not explicitly a mechanism of Xen, which is
-only concerned with the actual sharing of the page and not how it is
-used, they are however worth discussing as they are used in many
-places in the current code and are a useful model for communicating
-across a shared page.
-
-A shared page is set up by a front end guest first allocating and passing
-the address of a page in its own address space to the backend driver.
-
-Consider the following code, also from blkfront.c. Note: this code
-is in blkif_disconnect(). The driver transitions from STATE_CLOSED
-to STATE_DISCONNECTED before becoming CONNECTED. The state automata
-is in blkif_status().
-
- blk_ring = (blkif_ring_t *)__get_free_page(GFP_KERNEL);
- blk_ring->req_prod = blk_ring->resp_prod = resp_cons = req_prod = 0;
- ...
- /* Construct an interface-CONNECT message for the domain controller. */
- cmsg.type = CMSG_BLKIF_FE;
- cmsg.subtype = CMSG_BLKIF_FE_INTERFACE_CONNECT;
- cmsg.length = sizeof(blkif_fe_interface_connect_t);
- up.handle = 0;
- up.shmem_frame = virt_to_machine(blk_ring) >> PAGE_SHIFT;
- memcpy(cmsg.msg, &up, sizeof(up));
-
-
-blk_ring will be the shared page. The producer and consumer pointers
-are then initialised (these will be discussed soon), and then the
-machine address of the page is send to the backend via a control
-channel to Xend. This control channel itself uses the notification
-and shared memory mechanisms described here, but is set up for each
-domain automatically at startup.
-
-The backend, which is a privileged domain then takes the page address
-and maps it into its own address space (in
-linux26/drivers/xen/blkback/interface.c:blkif_connect()):
-
-
-void blkif_connect(blkif_be_connect_t *connect)
-
- ...
- unsigned long shmem_frame = connect->shmem_frame;
- ...
-
- if ( (vma = get_vm_area(PAGE_SIZE, VM_IOREMAP)) == NULL )
- {
- connect->status = BLKIF_BE_STATUS_OUT_OF_MEMORY;
- return;
- }
-
- prot = __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_DIRTY | _PAGE_ACCESSED);
- error = direct_remap_area_pages(&init_mm, VMALLOC_VMADDR(vma->addr),
- shmem_frame<<PAGE_SHIFT, PAGE_SIZE,
- prot, domid);
-
- ...
-
- blkif->blk_ring_base = (blkif_ring_t *)vma->addr
-}}}
-
-The machine address of the page is passed in the shmem_frame field of
-the connect message. This is then mapped into the virtual address
-space of the backend domain, and saved in the blkif structure
-representing this particular backend connection.
-
-NOTE: New mechanisms will be added very shortly to allow domains to
-explicitly grant access to their pages to other domains. This "grant
-table" support is in the process of being added to the tree, and will
-change the way a shared page is set up. In particular, it will remove
-the need of the remapping domain to be privileged.
-
-Sending data across shared rings:
-
-Shared rings avoid the potential for write interference between
-domains in a very cunning way. A ring is partitioned into a request
-and a response region, and domains only work within their own space.
-This can be thought of as a double producer-consumer ring -- the ring
-is described by four pointers into a circular buffer of fixed-size
-records. Pointers may only advance, and may not pass one another.
-
-
- resp_cons----+
- V
- +----+----+----+----+----+----+----+
- | | | free(A) |RSP1|RSP2|
- +----+----+----+----+----+----+----+
- req_prod->| | --------> |RSP3|
- +----+ +----+
- |REQ8| | |<-resp_prod
- +----+ +----+
- |REQ7| | |
- +----+ +----+
- |REQ6| <-------- | |
- +----+----+----+----+----+----+----+
- |REQ5|REQ4| free(B) | | |
- +----+----+----+----+----+----+----+
- req_cons---------^
-
-
-
-By adopting the convention that every request will receive a response,
-not all four pointers need be shared and flow control on the ring
-becomes very easy to manage. Each domain manages its own
-consumer pointer, and the two producer pointers are visible to both
-(xen/include/public/io/blkif.h):
-
-
-/* NB. Ring size must be small enough for sizeof(blkif_ring_t)
<=PAGE_SIZE.*/
- #define BLKIF_RING_SIZE 64
-
- ...
-
-/*
- * We use a special capitalised type name because it is _essential_ that all
- * arithmetic on indexes is done on an integer type of the correct size.
- */
-typedef u32 BLKIF_RING_IDX;
-
-/*
- * Ring indexes are ''free running''. That is, they are not
stored modulo the
- * size of the ring buffer. The following macro converts a free-running counter
- * into a value that can directly index a ring-buffer array.
- */
-#define MASK_BLKIF_IDX(_i) ((_i)&(BLKIF_RING_SIZE-1))
-
-typedef struct {
- BLKIF_RING_IDX req_prod; /* 0: Request producer. Updated by front-end. */
- BLKIF_RING_IDX resp_prod; /* 4: Response producer. Updated by back-end. */
- union { /* 8 */
- blkif_request_t req;
- blkif_response_t resp;
- } PACKED ring[BLKIF_RING_SIZE];
-} PACKED blkif_ring_t;
-
-
-
-As shown in the diagram above, the rules for using a shared memory
-ring are simple.
-
- 1. A ring is full when a domain''s producer and consumer pointers are
- equal (e.g. req_prod == resp_cons). In this situation, the
- consumer pointer must be advanced. Furthermore, if the consumer
- pointer is equal to the other domain''s producer pointer,
- (e.g. resp_cons = resp_prod), then the other domain has all the
- buffers.
-
-2. Producer pointers point to the next buffer that will be written to.
- (So blk_ring[MASK_BLKIF_IDX(req_prod)] should not be consumed.)
-
-3. Consumer pointers point to a valid message, so long as they are not
- equal to the associated producer pointer.
-
-4. A domain should only ever write to the message pointed
- to by its producer index, and read from the message at it''s
- consumer. More generally, the domain may be thought of to have
- exclusive access to the messages between its consumer and producer,
- and should absolutely not read or write outside this region.
-
- Thus the front end has exclusive access to the free(A) region
- in the figure above, and the back end driver has exclusive
- access to the free(B) region.
-
-In general, drivers keep a private copy of their producer pointer and
-then set the shared version when they are ready for the other end to
-process a set of messages. Additionally, it is worth paying attention
-to the use of memory barriers (rmb/wmb) in the code, to ensure that
-rings that are shared across processors behave as expected.
-
-==== Structure of the Blkif Drivers ===-
-Now that the communications primitives have been discussed, I''ll
-quickly cover the general structure of the blkif driver. This is
-intended to give a high-level idea of what is going on, in an effort
-to make reading the code a more approachable task.
-
-There are three key software components that are involved in the blkif
-drivers (not counting Xen itself). The frontend and backend driver,
-and Xend, which coordinates their initial connection. Xend may also
-be involved in control-channel signalling in some cases after startup,
-for instance to manage reconnection if the backend is restarted.
-
-===== Frontend Driver Structure ====-
-The frontend domain uses a single event channel and a shared memory
-ring to trade control messages with the backend. These are both setup
-during domain startup, which will be discussed shortly. The shared
-memory ring is called blkif_ring, and the private ring indexes are
-resp_cons, and req_prod. The ring is protected by blkif_io_lock.
-Additionally, the frontend keeps a list of outstanding requests in
-rec_ring[]. These are uniquely identified by a guest-local id number,
-which is associated with each request sent to the backend, and
-returned with the matching responses. Information about the actual
-disks are stored in major_info[], of which only the first nr_vbds
-entries are valid. Finally, the global ''recovery'' indicates
that the
-connection between the backend and frontend drivers has been broken
-(possibly due to a backend driver crash) and that the frontend is in
-recovery mode, in which case it will attempt to reconnect and reissue
-outstanding requests.
-
-The frontend driver is single-threaded and after setup is entered only
-through three points: (1) read/write requests from the XenLinux guest
-that it is a part of, (2) interrupts from the backend driver on its
-event channel (blkif_int()), and (3) control messages from Xend
-(blkif_ctrlif_rx).
-
-===== Backend Driver Structure ====-
-The backend driver is slightly more complex as it must manage any
-number of concurrent frontend connections. For each domain it
-manages, the backend driver maintains a blkif structure, which
-describes all the connection and disk information associated with that
-particular domain. This structure is associated with the interrupt
-registration, and allows the backend driver to have immediate context
-when it takes a notification from some domain.
-
-All of the blkif structures are stored in a hash table (blkif_hash),
-which is indexed by a hash of the domain id, and a "handle", really a
-per-domain blkif identifier, in case it wants to have multiple connections.
-
-The per-connection blkif structure is of type blkif_t. It contains
-all of the communication details (event channel, irq, shared memory
-ring and indexes), and blk_ring_lock, which is the backend mutex on
-the shared ring. The structure also contains vbd_rb, which is a
-red-black tree, containing an entry for each device/partition that is
-assigned to that domain. This structure is filled by xend passing
-disk information to the backend at startup, and is protected by
-vbd_lock. Finally, the blkif struct contains a status field, which
-describes the state of the connection.
-
-The backend driver spawns a kernel thread at startup
-(blkio_schedule()), which handles requests to and from the actual disk
-device drivers. This scheduler thread maintains a list of blkif
-structures that have pending requests, and services them round-robin
-with a maximum per-round request limit. blkifs are added to the list
-in the interrupt handler (blkif_be_int()) using
-add_to_blkdev_list_tail(), and removed in the scheduler loop after
-calling do_block_io_op(), which processes a batch of requests. The
-scheduler thread is explicitly activated at several points in the code
-using maybe_trigger_blkio_schedule().
-
-Pending requests between the backend driver and the physical device
-drivers use another ring, pending_ring. Requests are placed in this
-ring in the scheduler thread and issued to the device. A completion
-callback, end_block_io_op, indicates that requests have been serviced
-and generates a response on the appropriate blkif ring. pending
-reqs[] stores a list of outstanding requests with the physical drivers.
-
-So, control entries to the backend are (1) the blkio scheduler thread,
-which sends requests to the real device drivers, (2) end_block_io_op,
-which is called as serviced requests complete, (3) blkif_be_int()
-handles notifications from the frontend drivers in other domains, and
-(4) blkif_ctrlif_rx() handles control messages from xend.
-
-==== Driver Startup ===-
-Prior to starting a new guest using the frontend driver, the backend
-will have been started in a privileged domain. The backend
-initialisation code initialises all of its data structures, such as
-the blkif hash table, and starts the scheduler thread as a kernel
-thread. It then sends a driver status up message to let xend know it
-is ready to take frontend connections.
-
-When a new domain that uses the blkif frontend driver is started,
-there are a series of interactions between it, xend, and the specified
-backend driver. These interactions are as follows:
-
-The domain configuration given to xend will specify the backend domain
-and disks that the new guest is to use. Prior to actually running the
-domain, xend and the backend driver interact to setup the initial
-blkif record in the backend.
-
-(1) Xend sends a BLKIF_BE_CREATE message to backend.
-
- Backend does blkif_create(), having been passed FE domid and handle.
- It creates and initialises a new blkif struct, and puts it in the
- hash table.
- It then returns a STATUS_OK response to xend.
-
-(2) Xend sends a BLKIF_BE_VBD_CREATE message to the backend.
-
- Backend adds a vbd entry in the red-black tree for the
- specified (dom, handle) blkif entry.
- Sends a STATUS_OK response.
-
-(3) Xend sends a BLKIF_BE_VBD_GROW message to the backend.
-
- Backend takes the physical device information passed in the
- message and assigns them to the newly created vbd struct.
-
-(2) and (3) repeat as any additional devices are added to the domain.
-
-At this point, the backend has enough state to allow the frontend
-domain to start. The domain is run, and eventually gets to the
-frontend driver initialisation code. After setting up the frontend
-data structures, this code continues the communications with xend and
-the backend to negotiate a connection:
-
-(4) Frontend sends Xend a BLKIF_FE_DRIVER_STATUS_CHANGED message.
-
- This message tells xend that the driver is up. The init function
- now spin-waits until driver setup is complete in order to prevent
- Linux from attempting to boot before the disks are connected.
-
-(5) Xend sends the frontend an INTERFACE_STATUS_CHANGED message
-
- This message specifies that the interface is now disconnected
- (instead of closed).
- The domain updates it''s state, and allocates the shared blk_ring
- page. Next,
-
-(6) Frontend sends Xend a BLKIF_INTERFACE_CONNECT message
-
- This message specifies the domain and handle, and includes the
- address of the newly created page.
-
-(7) Xend sends the backend a BLKIF_BE_CONNECT message
-
- The backend fills in the blkif connection information, maps the
- shared page, and binds an irq to the event channel.
-
-(8) Xend sends the frontend an INTERFACE_STATUS_CHANGED message
-
- This message takes the frontend driver to a CONNECTED state, at
- which point it binds an irq to the event channel and calls
- xlvbd_init to initialise the individual block devices.
-
-The frontend Linux is stall spin waiting at this point, until all of
-the disks have been probed. Messaging now is directly between the
-front and backend domain using the new shared ring and event channel.
-
-(9) The frontend sends a BLKIF_OP_PROBE directly to the backend.
-
- This message includes a reference to an additional page, that the
- backend can use for it''s reply. The backend responds with an array
- of the domains disks (as vdisk_t structs) on the provided page.
-
-The frontend now initialises each disk, calling xlvbd_init_device()
-for each one.
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/cpuid-config-for-guest.txt
--- a/docs/misc/cpuid-config-for-guest.txt Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,23 +0,0 @@
-CPUID emulation for guest
--------------------------
-
-When HVM guest tries to execute CPUID, or PV guest tries to execute XEN_CPUID,
-the xen hypervior traps and emultes them.
-
-For HVM guest and PV DomU guest, xen''s CPUID emulation can be adjusted
using
-the guest configation file if necessary (e.g., to supply better support for
-guest live migration). The CPUID syntax in guest configration file is
-described in detail in the examples like /etc/xen/xmexample.hvm,
-/etc/xen/xmexample.hvm-stubdom.
-
-However, a user (or an administrator) must be aware that the CPUID in guest
-configuration file can NOT be configured casually. The default CPUID
-configuration should be safe, but illegal configuration can cause unexpected
-behaviors of guest -- even can crash guest.
-
-For example, we should not expose the MONITOR CPUID feature flag (ECX bit 3;
-CPUID executed EAX = 1) to HVM guest, otherwise, on guest''s attempt of
-executing MWAIT, the VMExit handler in Xen would inject #UD (Invalid Opcode
-Exception) into the HVM guest, and guest kernel would panic.
-
-/* We can add more unsafe CPUID configuration here in future. */
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/hg-cheatsheet.txt
--- a/docs/misc/hg-cheatsheet.txt Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,438 +0,0 @@
-
-Mercurial(hg) Cheatsheet for Xen
-===============================-
-Written by Andrew Warfield, extended by Michael Fetterman and Ian Pratt
-June 29, 2005, extended by Grzegorz Milos 04 July 2005.
-
-Overview
---------
-The Xen project has moved from BitKeeper to Mercurial for source
-control. This note aims to provide a quick guide to getting up and
-running with the new tools as quickly as possible, and is written from
-the perspective of someone who has been using BK.
-
-For a more detailed exposition, see the mercurial tutorial:
- http://www.serpentine.com/mercurial/index.cgi?Tutorial
-
-The Hg manpage is available at:
- http://www.selenic.com/mercurial/hg.1.html
-
-There''s also a very useful FAQ that explains the terminology:
- http://www.selenic.com/mercurial/FAQ.html
-
-There''s also a good README:
- http://www.selenic.com/mercurial/README
-
-Necessary software
-------------------
-Mercurial is available at:
- http://www.selenic.com/mercurial/
-
-You will also need a Python version >= 2.3
-
-How Mercurial is different from BK
-----------------------------------
-There are several pertinent differences between hg and bk. This
-section aims to give an overview of the conceptual differences between
-the two SCMs -- if you just want examples to get going, skip ahead to
-"Getting Xen". The key differences are:
-
- - No explicit per-file locking. You do not need to explicitly
- check a file out before editing it.
- - No notion (currently) of file renames.
- - A repository can have multiple active heads.
- - Automatic merge support is currently inferior to BK''s.
- - No graphical tools.
- - No per-file revision history, only per-changeset (we never really used this
anyhow)
- - Hg repositories tend to be rather bigger than Bk ones, but Hg does seem
faster.
-
-Mercurial is based on the notion of changesets as complete, immutable,
-versions of the repository. You make changes to a working version of
-the repository that is based on a particular changeset. When you
-commit, you will generate a new child changeset with whatever changes
-you choose to apply.
-
-A major difference between Hg and BK is that you aren''t forced to
-resolve conflicts immediately: BK forced you to resolve conflicts
-immediately on any merge, and it then immediately created a changeset
-with those conflicts'' resolutions. Frequently, you then had to add
-yet another changeset to fixup the things for which the automatic
-merge yielded bad results. Hg puts the results of the merge into your
-work directory, and remembers what you merged with (so that it can
-later record both of the merge parents, if you decide to make a
-changeset), but it doesn''t immediately create a changeset.
-
-A further feature of Hg is that it allows a repository to have
-multiple heads. This means that you can have changesets with no common
-descendent in one repository -- something BK won''t allow. This is
-actually pretty neat. For example, it would in principle enable you to
-have both the 2.0-testing and unstable trees in a single
-repository. We shyed away from doing this as we thought the risk of
-committing to the wrong head was too great.
-
-One slightly confusing aspect of Hg is that many of the commands have
-aliases, and hence when looking things up in the man page its not
-always obvious what the underlying command is. For example
''co'' is
-actually an alias for the ''update'' command, but
''co'' seems to make
-more sense, at least to RCS refugees like me.
-
-
-Getting Xen
------------
-
-The URL for the mainline Xen mercurial repository is:
-
- http://xenbits.xensource.com/xen-unstable.hg
- (similarly for xen-2.0 and xen-2.0-testing)
-
-You can point a browser and this and use Hg''s web interface to view
-revision history, or use it as the nominated source when issuing
-"hg init" or "hg pull" commands.
-
-However, to avoid taxing the Mercurial server with a complete pull of
-the Xen repository, it is best to download a tarball of a seed
-repository from:
-
-
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-unstable.hg.tar.gz
-
- (or copy from /usr/groups/netos/html/xen/downloads/xen-unstable.hg.tar.gz)
-
-Untar the repository on your disk, cd into it, and then pull the most
-recent changes:
-
- hg pull -u
-
-By default hg does not automatically checkout (''update'')
files from
-the repository as used to happen with bk. The above is equivalent to
-"hg pull; hg co"
-
-The repository parent is stored in a repository configuration file,
-.hg/hgrc, from the repository root. If you look at this file, you
-will see:
-
- | [paths]
- | default = http://xenbits.xensource.com/xen-unstable.hg
-
-"default" specifies the appropriate parent repository for hg to pull
-from. Hg allows you to pull additional repositories, for instance if
-you want to work between unstable and testing concurrently.
-
-The command "hg pull" simply adds changesets to your repository,
-without any merging of any kind. "hg pull -u" implies merging with
-the current state of your working directory. If you weren''t already
-"updated" to your local repository''s tip, you might be
surprised to
-find yourself merging the results of the pull with a non-tip node in
-your local repository.
-
-
-Revision History
-----------------
-
-You can view the repository revision history with:
-
- hg history
-
-In practice, you''ll probably want to use pipe the output through
-''head'' or ''more'' as it prints the entire
history.
-
-Looking at the first few lines of output, you can see the changeset at
-the head of the current branch, known as the ''tip'' (the tip
is
-automatically given a special tag to make it easy to refer to):
-
- | changeset: 5599:6cbf9ec05cd9e05c0c46a85df7fc00262633cd3d
- | tag: tip
- | user: kaf24@firebug.cl.cam.ac.uk
- | date: Tue Jun 28 18:47:14 2005
- | summary: bitkeeper revision 1.1768 (42c18d2259NPELcGV7ohyZNh72ufSw)
-
-By default, Hg just shows the first line of the changset comments. You
-can find further information with "hg -v history".
-
-The changeset identifier has two parts, a _local_ monotonically
-increasing changeset id, 5599 above, and a _global_ hash, which
-follows the colon on the changeset line. The hash uniquely identifies
-the changeset and its lineage back to the root of the changeset tree
--- it is useful for distributed management and so on. However, as it
-is a bit unruly, the local id will allow you to work easily with the
-local repo. Hg commands will take either identifier. Additionally, a
-tags mechanism lets you give common names to specific changesets.
-
-You should always use the global hash when referring to versions of
-the mainline Xen respoitory. With Bk you could often get away with
-using the shortform version, but with Hg the local ids are pretty much
-guaranteed to be different.
-
-
-Creating a child repository from an existing repository
--------------------------------------------------------
-If you wanted to create additional local child repositories,
-
- hg init [path or url]
-
-is effectively equivalent to bk clone. The major difference is that
-it should be run from the root of your new repository. So:
-
- bk clone /foo/bar
-
-would be replaced with:
-
- mkdir bar
- cd bar
- hg init /foo/bar
-
-NB: newer version of Hg support a ''clone'' command that works
in the
-same manner as bk.
-
-Editing files
--------------
-
-Normal edits may be made in place. File creation needs explicit
-marking, though deletes should be picked up automatically
-
-creation:
-
- touch a.txt (or otherwise created a file)
- hg add a.txt
-
-You can see what has changed using:
-
- hg status
-
- | C foo/foo.c
- | R foo/bar.c
- | ? a.txt
-
-This shows that in the current repo, foo.c has been changed, bar.c has
-been deleted, and a.txt is new, but has not been added. ''?''
changes
-to ''A'' after "hg add a.txt". There is a .hgignore
file which contains
-regexps of files that should be ignored when scanning for new
-files. We try to ensure that all the generated files in a build are
-covered by the regexps.
-
-You can add all the new files in a repository with "hg addremove". If
-you discover that you''ve added a file you didn''t want, you
can remove
-it from the list of files to be included in the next commit using
-"hg forget".
-
-Committing changes
------------------
-
-After you''ve checked that hg knows about any new files you''ve
created,
-you probably want to see a diff of what you''re about to commit. You
-can do this with:
-
- hg diff
-
-Once you''re happy with what you have, invoke:
-
- hg commit
-
-This will pop up an editor with a list of files to be committed to the
-repository. It will look vaguely like this:
-
- |
- | HG: manifest hash 6397b04bd5c2a992482d973b685a7e5e498788e7
- | HG: changed doc/thesis/new.tex
- | HG: removed doc/2005-hotdep-protection/paper.tex
-
-Your comments can go anywhere in this file. The first line is the
-most important, as it will show as the changeset description in
-non-verbose-mode history listings.
-
-You can do commits without the editor and of partial sets of files
-using command-line switches. See:
-
- hg help commit
-
-You can use the -A (--addremove) flag to commit e.g. "hg -A commit"
to
-ask mercurial to scan the tree looking for newly created files to add
-in to the changeset. This avoids having to explicitly use "hg add",
-but you probably want to be careful of adding any new generated files
-too.
-
-
-Generating a patch
-------------------
-Generating a patch is easy,
-
- hg export [changeset]
-
-will generate a patch describing the diff between that changeset and
-its parent.
-
-To generate a patch between two specified revisions use:
- hg diff -r A -r B [files]
-NB: BK syntax -rA..B isn''t supported by Hg.
-
-
-Pushing changesets to a parent repository
------------------------------------------
-
- hg push
-
-Pushes changes up to a parent. You can''t push if you pulled the
-repository off the web interface. In fact, you can currently only push
-to an ssh target -- filesystem directory targets don''t work, but this
-will be fixed soon.
-For now it is possible to set up asymmetric pull/push paths. Pulls can
-be done via web interface while pushes via ssh. Example of .hg/hgrc config
-file:
- | [paths]
- | default = http://your.server/repository_name
- | default-push = ssh://[username@]your.server//repository_location
-
-
-Repository history
-------------------
-
-Here are a collection of common commands to get you started:
-
- hg history | less
-
-shows the history of changesets, starting from the most recent. You
-want to pipe it to some sort of pager. For more complete details,
-
- hg -v history | less
-
-will include files modified and full (not just first-line) comments.
-
-Additionally, you can see just the tip (head of the current
-branch) of the repository by typing:
-
- hg [-v] tip
-
-
-Moving to a specific changeset
-------------------------------
-
-The co command lets you change the working version of the repository
-to a different changeset.
-
- hg co [changeset]
-
-NB: ''co'' is an alias for ''update''
-
-This command enables you to rewind the working repository to previous
-changesets, for example to isolate the changeset in which a bug is
-introduced.
-
-If you try and do a ''co'' but have modified files in your
repository Hg
-won''t let you unless you ask it explicitly to merge the checked out
-version into the current tree using the "-m" option. The
"-C"
-(--clean) option will force overwrite any locally modified files.
-
-Any commits that are made to non-head changesets will obviously fork
-the tree, creating a new head. You can see all the heads in a tree with
-"hg heads".
-
-In general, "hg co" does the right thing, although it
doesn''t
-currently seem to clean up unused directories that have been created
-by other checked-out versions. This can confuse the Xen build
-system. Hg will probably get fixed soon, but in the meantime you can
-cleanup with "find -depth -type d -print | xargs -r rmdir".
-
-You can return to the tip by omitting an explicit changeset id.
-
-The manifest command lets you see the contents of the repository for
-the current changeset.
-
- hg manifest
-
-This will print a bunch of records of the form:
-
- | 98856c45c35a504bc6da06a62b7787ddfdfd1c8b 644 COPYING
- | f28971eedc5b54e7a9b26dd18d52992955354981 644 Config.mk
- | a3575cc4db59e50bbac8a039a0c74f081a8dfc4f 644 Makefile
- | 7fc869aae2945a9f4626fad96552db3103e61cb9 644 README
- | ...
-
-This lists the hash of each file, its 1-bit ''executable''
attribute
-(either file permission mode 644 or 755), and the file name. So, to
-determine the files that change across two changesets, you would dump
-the respective manifests to files, and use diff.
-
-
-Managing changeset tags
------------------------
-To create a tag to the current changeset:
-
- hg tag tagname
-
-This will _immediately_ generate a changeset with a change to the file
-.hgtags in the repository root. The new tag in this file will look
-something like:
-
- | 35159ed4b30538e7a52c60ad0a63f7e9af156e4c tagname
-
-and may be used to identify that changeset throughout the repo.
-Storing tags in this file and generating changesets immediately
-forces people to merge and keep tags up to date across the repository.
-
-Note that tags are resolved by searching .hgtags in each of the
-repository heads, sequentially, and using the first match. "hg
heads"
-lists the current heads.
-
-The "hg tags" command, will lists all the currently valid tags.
-
-
-Hg server and source browser
-----------------------------
-
- hg serve -p port
-
-Launches a web server on the specified port, serving a source browser
-for the repository. This browser may be used to examine the
-changeset history, view annotated source files, generate diffs.
-Additionally "hg pull" may be run against it.
-
-Additional useful commands
-(that probably only need one-line descriptions)
------------------------------------------------
-
-(Slightly) more detail on all of these is available with
-
- hg help [command]
-
-Shows the differences between whatever changeset you most recently
-checked out, and your current working directory:
-
- hg diff
-
-View an annotated version of a source file:
-
- hg annotate
-
-Get a historical version of a file:
-
- hg cat
-
- NB: Most commands accepting a version number want the changeset''s
- version number. "hg cat" is different in that it wants the
- *file*''s version number.
-
-Unadd a file to the current commit:
-
- hg forget
-
-List all heads in the current repository:
-
- hg heads
-
-Undo exactly one (and ONLY one) changeset:
-
- hg undo
-
-Show the parents of a changeset:
-
- hg parents
-
- NB: Changesets have either one or two parent changesets. If your
- working directory contains the uncommitted results of a merge, then
- you have two parents. Otherwise, the single parent is the changeset
- which you most recently checked out.
-
-Show the revision history for a single file
-
- hg [-v] log <filename>
-
diff -r 617f5d6e9e69 -r 55ce23cb7b2a docs/misc/network_setup.txt
--- a/docs/misc/network_setup.txt Thu Nov 17 14:54:12 2011 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,196 +0,0 @@
-Native OS bridge configuration
-=============================-
-The traditional "network-bridge" script attempts to modify existing
active
-network interfaces to enable bridging. For non-trivial network configurations
-though this can be error prone, and the temporary disruption to network
-connectivity can upset some applications. This document outlines how to
-configure bridging using an OS'' native network configuration files.
-
-Disabling Xen''s network scripts
--------------------------------
-
-The first step is to check XenD''s network bridge is disabled by
-editing /etc/xen/xend-config.sxp and changing the line
-
- (network-script network-bridge)
-
-To be
-
- (network-script /bin/true)
-
-
-Fedora/RHEL Bridging
-===================-
-This outlines how to setup bridging using standard network initscripts
-present in Fedora or RHEL distros and their derivatives
-
-
-Disabling NetworkManager
-------------------------
-
-As of time of writing (Fedora 14) NetworkManager does not support bridging,
-so it is neccessary to disable NetworkManager, and revert to
"classic"
-network initscripts
-
- # chkconfig NetworkManager off
- # chkconfig network on
- # service NetworkManager stop
- # service network start
-
-NB, as an alternative to turning off NetworkManager, you can also add a line
-"NM_CONTROLLED=no" to the ifcfg-XXX scripts below
-
-Creating network initscripts
-----------------------------
-
-In the /etc/sysconfig/network-scripts directory it is necccessary to create
-2 config files. The first (ifcfg-eth0) defines your physical network interface,
-and says that it will be part of a bridge:
-
-# cat > ifcfg-eth0 <<EOF
-DEVICE=eth0
-HWADDR=00:16:76:D6:C9:45
-ONBOOT=yes
-BRIDGE=br0
-EOF
-
-Obviously change the HWADDR to match your actual NIC''s address. You
may also
-wish to configure the device''s MTU here using e.g. MTU=9000.
-
-The second config file (ifcfg-br0) defines the bridge device:
-
-# cat > ifcfg-br0 <<EOF
-DEVICE=br0
-TYPE=Bridge
-BOOTPROTO=dhcp
-ONBOOT=yes
-DELAY=0
-EOF
-
-WARNING: The line TYPE=Bridge is case-sensitive - it must have uppercase
-''B'' and lower case ''ridge''
-
-After changing this restart networking (or better still reboot)
-
- # service network restart
-
-
-The final step is to configure iptables to allow all traffic to be
-forwarded across the bridge
-
-# echo "-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT" >
/etc/sysconfig/iptables-forward-bridged
-# lokkit --custom-rules=ipv4:filter:/etc/sysconfig/iptables-forward-bridged
-# service libvirtd reload
-
-Alternatively, you can prevent bridged traffic getting pushed through
-the host''s iptables rules completely. In /etc/sysctl.conf add
-
- # cat >> /etc/sysctl.conf <<EOF
- net.bridge.bridge-nf-call-ip6tables = 0
- net.bridge.bridge-nf-call-iptables = 0
- net.bridge.bridge-nf-call-arptables = 0
- EOF
- # sysctl -p /etc/sysctl.conf
-
-You should now have a "shared physical device", to which guests can
be
-attached and have full LAN access
-
- # brctl show
- bridge name bridge id STP enabled interfaces
- br0 8000.000e0cb30550 no eth0
-
-
-
-Debian/Ubuntu Bridging
-======================-
-This outlines how to setup bridging using standard network interface config
files
-on Debian / Ubuntu distributions and their derivatives
-
-Disabling NetworkManager
-------------------------
-
-Stop network manager
-
- sudo /etc/dbus-1/event.d/26NetworkManagerDispatcher stop
- sudo /etc/dbus-1/event.d/25NetworkManager stop
-
-Create two files with only the word ''exit'' in them. These
files are:
-
- /etc/default/NetworkManager
- /etc/default/NetworkManagerDispatcher
-
-
-Altering the interface config
------------------------------
-
-First take down the interface you wish to bridge
-
- ifdown eth0
-
-Edit /etc/network/interfaces and find the config for the physical
-interface, which looks something like
-
- allow-hotplug eth0
- iface eth0 inet static
- address 192.168.2.4
- netmask 255.255.255.0
- network 192.168.2.0
- broadcast 192.168.2.255
- gateway 192.168.2.2
-
-Remove the ''allow-hotplug eth0'' line, replacing it with
''auto br0'',
-and change the next line with iface name to ''br0'', so it now
starts
-with
-
- auto br0
- iface br0 inet static
-
-And then define the interface as being a bridge and specify its ports
-
- bridge_ports eth0
- bridge_stp off
- bridge_maxwait 5
-
-The complete config should now look like
-
- auto br0
- iface br0 inet static
- address 192.168.2.4
- netmask 255.255.255.0
- network 192.168.2.0
- broadcast 192.168.2.255
- gateway 192.168.2.2
- bridge_ports eth0
- bridge_stp off
- bridge_maxwait 5
-
-The interface can now be started with
-
- ifup br0
-
-Finally add the ''/etc/sysctl.conf'' settings
-
-net.bridge.bridge-nf-call-ip6tables = 0
-net.bridge.bridge-nf-call-iptables = 0
-net.bridge.bridge-nf-call-arptables = 0
-
-And then load the settings with
-
- sysctl -p /etc/sysctl.conf
-
-
-You should now have a "shared physical device", to which guests
-can be attached and have full LAN access
-
- # brctl show
- bridge name bridge id STP enabled interfaces
- br0 8000.000e0cb30550 no eth0
-
-
-Other operating systems / distributions
-======================================-
-[...send patches to this file with instructions....]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 12 of 17] docs: tweak markup and wording of qemu upstream doc slightly
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321541678 0
# Node ID c1f8406da50743cd0597b93c4b5b8b6ff03ede42
# Parent 55ce23cb7b2af3c497b3a10658e09d5fc11eb45f
docs: tweak markup and wording of qemu upstream doc slightly
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r 55ce23cb7b2a -r c1f8406da507
docs/misc/qemu-upstream_howto_use_it.markdown
--- a/docs/misc/qemu-upstream_howto_use_it.markdown Thu Nov 17 14:54:38 2011
+0000
+++ b/docs/misc/qemu-upstream_howto_use_it.markdown Thu Nov 17 14:54:38 2011
+0000
@@ -1,11 +1,11 @@
-Help to use QEMU (upstream version) with Xen
-===========================================+Using Upstream QEMU with Xen
+===========================
Note
----
All these steps will become unnecessary after the patches to integrate
-SeaBIOS/QEMU build will be applied.
+SeaBIOS/QEMU into the Xen build system have been applied.
How to build it
@@ -15,14 +15,15 @@ How to build it
The new device-model needs a different BIOS, SeaBIOS. Clone the repository
from:
- - git://git.qemu.org/seabios.git
- - http://git.qemu.org/git/seabios.git
+ - [git://git.qemu.org/seabios.git]()
+ - [http://git.qemu.org/git/seabios.git]()
-Put the `.config` file in the appendix at the root of seabios.git and build
SeaBIOS.
+Put the `.config` file in the appendix at the root of `seabios.git`
+and build SeaBIOS by typing `make`.
-In xen-unstable source tree, add the file `.config` with
+In the xen-unstable source tree, add the file `.config` with
`SEABIOS_DIR = /path/to/seabios.git`.
-To build hvmloader with SeaBIOS, you propably need to `make -C tools/firmware
+To build hvmloader with SeaBIOS, you probably need to `make -C tools/firmware
clean` first and then `make tools`, to use the new SEABIOS_DIR parameter.
@@ -30,10 +31,10 @@ clean` first and then `make tools`, to u
Get QEMU upstream source from:
- - git://xenbits.xensource.com/qemu-upstream-unstable.git
- - http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git
+ - [git://xenbits.xensource.com/qemu-upstream-unstable.git]()
+ - [http://xenbits.xensource.com/git-http/qemu-upstream-unstable.git]()
-To configure build QEMU upstream with Xen
+To configure QEMU upstream with support for Xen:
./configure --enable-xen --target-list=i386-softmmu
--extra-cflags="-I$path_to_xen_source/tools/include
-I$path_to_xen_source/tools/libxc -I$path_to_xen_source/tools/xenstore"
--extra-ldflags="-L$path_to_xen_source/tools/libxc
-L$path_to_xen_source/tools/xenstore"
@@ -43,15 +44,15 @@ You can also use other several options s
How to use QEMU upstream
------------------------
-Only xl support QEMU upstream.
+Only `xl` supports QEMU upstream.
To actually use it, add or change this in your VM configuration file:
device_model_version = ''qemu-xen''
device_model_override = ''/path/to/qemu/i386-softmmu/qemu''
-NB: On qemu-upstream repository, the default binary name has been renamed to
-`qemu-system-i386`.
+NB: In the `qemu-upstream` repository, the default binary name has been
+renamed to `qemu-system-i386`.
Appendix
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:01 UTC
[Xen-devel] [PATCH 13 of 17] docs: generate an index for the html output
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542075 0
# Node ID 8f2404eef8fac8020528b408b3a958d81cbb73c0
# Parent c1f8406da50743cd0597b93c4b5b8b6ff03ede42
docs: generate an index for the html output
nb: I''m not a Perl wizard...
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r c1f8406da507 -r 8f2404eef8fa docs/INDEX
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/INDEX Thu Nov 17 15:01:15 2011 +0000
@@ -0,0 +1,5 @@
+misc/hvm-emulated-unplug Xen HVM emulated device unplug protocol
+
+# These are not all that useful anymore, hide them from the index
+interface/index NO-INDEX
+user/index NO-INDEX
diff -r c1f8406da507 -r 8f2404eef8fa docs/Makefile
--- a/docs/Makefile Thu Nov 17 14:54:38 2011 +0000
+++ b/docs/Makefile Thu Nov 17 15:01:15 2011 +0000
@@ -45,7 +45,7 @@ ps: $(DOC_PS)
pdf: $(DOC_PDF)
.PHONY: html
-html: $(DOC_HTML)
+html: $(DOC_HTML) html/index.html
.PHONY: txt
txt: $(DOC_TXT)
@@ -128,6 +128,9 @@ html/%/index.html: src/%.tex
$< 1>/dev/null 2>/dev/null ; else \
echo "latex2html not installed; skipping $*."; fi
+html/index.html: $(DOC_HTML) ./gen-html-index INDEX
+ ./gen-html-index -i INDEX html $(DOC_HTML)
+
html/%.html: %.markdown
@$(INSTALL_DIR) $(@D)
@set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \
diff -r c1f8406da507 -r 8f2404eef8fa docs/gen-html-index
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/gen-html-index Thu Nov 17 15:01:15 2011 +0000
@@ -0,0 +1,129 @@
+#!/usr/bin/perl -w
+
+#
+# Generate indexes for html documentation
+#
+
+use strict;
+use warnings;
+
+use Getopt::Long;
+use IO::File;
+use File::Basename;
+use List::MoreUtils qw/ uniq /;
+
+Getopt::Long::Configure(''bundling'');
+
+@ARGV >= 2 or die;
+
+our @docs;
+our @dirs;
+our %index;
+
+our $outdir;
+
+GetOptions("i=s" => sub { read_index(@_);} )
+ or die;
+
+($outdir,@docs) = @ARGV;
+
+sub write_file ($$) {
+ my ($opath, $odata) = @_;
+ my $out = new IO::File "$opath.new", ''>'' or
die "$opath $!";
+ print $out $odata or die $!;
+ rename "$opath.new", "$opath" or die "$opath
$!";
+}
+
+sub make_page($$$) {
+ my ($file,$title,$content) = @_;
+ my $o = '''';
+ my $h1;
+ if ( $title eq "" )
+ {
+ $title = $h1 = "Xen Documentation";
+ }
+ else
+ {
+ $h1 = "<a href=\"../index.html\">Xen
Documentation</a> - $title";
+ $title = "Xen Documentation - $title";
+ }
+ $o .= <<END;
+<html><head><title>$title</title></head>
+<body>
+<h1>$h1</h1>
+<ul>
+$content
+</ul>
+</body></html>
+END
+ print STDERR "Writing: $file\n";
+ write_file($file, $o);
+}
+
+sub make_linktext($) {
+ my ($l) = @_;
+ return "$1($2)" if $l =~ m,^man/(.*)\.([0-9].*)\.html,;
+ $l =~ s/.(html)$//g;
+ return $index{$l} if exists $index{$l};
+ return basename($l);
+}
+
+sub make_link($$) {
+ my ($ref,$base) = @_;
+
+ my $txt = make_linktext($ref);
+ $ref = basename($ref) if $base;
+
+ return "<li><a
href=\"$ref\">$txt</a></li>\n";
+}
+
+sub make_links($$@) {
+ my ($dir,$base,@docs) = @_;
+ my $idx = '''';
+ foreach my $of (sort { $a cmp $b } @docs) {
+ $idx .= make_link($of,$base);
+ }
+ return $idx;
+}
+
+sub read_index
+{
+ my ($opt, $val) = @_;
+ my $idx = new IO::File "$val", ''<'' or die
"$val $!";
+ while ($_ = $idx->getline()) {
+ s/#.*$//;
+ m/./ or next;
+ m/([^\t]+)\t+(.*)/ or die;
+ $index{$1} = $2;
+ }
+}
+
+for (@docs) { s,^${outdir}/,, }
+
+@docs = grep { -e "$outdir/$_" && (make_linktext($_) ne
"NO-INDEX") } @docs;
+
+my $top = '''';
+
+foreach my $od (sort { $a cmp $b } uniq map { dirname($_) } @docs) {
+ my @d = (grep /^$od/, @docs);
+ if ( $#d == 0 and $d[0] eq "$od/index.html" )
+ {
+ $top .= "<li><a
href=\"${od}/index.html\">${od}/index.html</a></li>\n";
+ }
+ else
+ {
+ $top .= "<li><a
href=\"${od}/index.html\">$od</a></li>\n";
+ $top .= "<ul>\n";
+ $top .= make_links($od,0,@d);
+ $top .= "</ul>\n";
+
+ my $idx = '''';
+ $idx .= "<li>$od</li>\n";
+ $idx .= "<ul>\n";
+ $idx .= make_links($od,1,@d);
+ $idx .= "</ul>\n";
+ make_page("$outdir/$od/index.html", $od, $idx);
+ }
+}
+
+make_page("$outdir/index.html", "", $top);
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:02 UTC
[Xen-devel] [PATCH 14 of 17] docs: move user and interface .tex documents under reference
# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1321542088 0 # Node ID 7d77e0269af797cb8ab8e7d536412a222e7da3ef # Parent 8f2404eef8fac8020528b408b3a958d81cbb73c0 docs: move user and interface .tex documents under reference. Taking over the top level "user" entry with a relatively obsolete document is a bit of an annoyance but these docs are not so out of date that they should be deleted. Move them out of the top-level instead. (the original motivation here was to allow for user/xl-domain-cfg.markdown but we have since decided to go with man/xl.cfg.pod.5 instead so perhaps this is a waste of time) Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r 8f2404eef8fa -r 7d77e0269af7 docs/INDEX --- a/docs/INDEX Thu Nov 17 15:01:15 2011 +0000 +++ b/docs/INDEX Thu Nov 17 15:01:28 2011 +0000 @@ -1,5 +1,5 @@ misc/hvm-emulated-unplug Xen HVM emulated device unplug protocol # These are not all that useful anymore, hide them from the index -interface/index NO-INDEX -user/index NO-INDEX +reference/interface/index NO-INDEX +reference/user/index NO-INDEX diff -r 8f2404eef8fa -r 7d77e0269af7 docs/Makefile --- a/docs/Makefile Thu Nov 17 15:01:15 2011 +0000 +++ b/docs/Makefile Thu Nov 17 15:01:28 2011 +0000 @@ -14,7 +14,7 @@ DOC_TEX := src/user.tex src/interface.t DOC_MARKDOWN := $(wildcard misc/*.markdown) DOC_PS := $(patsubst src/%.tex,ps/%.ps,$(DOC_TEX)) DOC_PDF := $(patsubst src/%.tex,pdf/%.pdf,$(DOC_TEX)) -DOC_HTML := $(patsubst src/%.tex,html/%/index.html,$(DOC_TEX)) \ +DOC_HTML := $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \ $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \ $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \ $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC)) @@ -119,14 +119,14 @@ ps/%.ps: %.dvi %.eps: %.fig $(FIG2DEV) -L eps $< $@ -html/%/index.html: src/%.tex +html/reference/%/index.html: src/%.tex @$(INSTALL_DIR) $(@D) @set -e ; if which $(LATEX2HTML) 1>/dev/null 2>/dev/null; then \ - echo "Running latex2html to generate $*/index.html ... "; \ + echo "Running latex2html to generate reference/$*/index.html ... "; \ $(LATEX2HTML) -split 0 -show_section_numbers -toc_depth 3 -nonavigation \ -numbered_footnotes -local_icons -noinfo -math -dir $(@D) \ $< 1>/dev/null 2>/dev/null ; else \ - echo "latex2html not installed; skipping $*."; fi + echo "latex2html not installed; skipping reference/$*."; fi html/index.html: $(DOC_HTML) ./gen-html-index INDEX ./gen-html-index -i INDEX html $(DOC_HTML) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:02 UTC
[Xen-devel] [PATCH 15 of 17] libxlu: add xlu_cfg_get_list_as_string_list
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542095 0
# Node ID 29d91e4d1f4f8d9233014b616547a9aed53b1515
# Parent 7d77e0269af797cb8ab8e7d536412a222e7da3ef
libxlu: add xlu_cfg_get_list_as_string_list
Returns a cfg list as a libxl_string_list.
Use this to simplify the parsing of device model extra args.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r 7d77e0269af7 -r 29d91e4d1f4f tools/libxl/libxlu_cfg.c
--- a/tools/libxl/libxlu_cfg.c Thu Nov 17 15:01:28 2011 +0000
+++ b/tools/libxl/libxlu_cfg.c Thu Nov 17 15:01:35 2011 +0000
@@ -254,6 +254,29 @@ int xlu_cfg_get_list(const XLU_Config *c
return 0;
}
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+ libxl_string_list *psl, int dont_warn) {
+ int i, rc, nr;
+ XLU_ConfigList *list;
+ libxl_string_list sl;
+
+ rc = xlu_cfg_get_list(cfg, n, &list, &nr, dont_warn);
+ if (rc) return rc;
+
+ sl = malloc(sizeof(char*)*(nr + 1));
+ if (sl == NULL) return ENOMEM;
+
+ for (i=0; i<nr; i++) {
+ const char *a = xlu_cfg_get_listitem(list, i);
+ sl[i] = a ? strdup(a) : NULL;
+ }
+
+ sl[nr] = NULL;
+
+ *psl = sl;
+ return 0;
+}
+
const char *xlu_cfg_get_listitem(const XLU_ConfigList *set, int entry) {
if (entry < 0 || entry >= set->nvalues) return 0;
return set->values[entry];
diff -r 7d77e0269af7 -r 29d91e4d1f4f tools/libxl/libxlutil.h
--- a/tools/libxl/libxlutil.h Thu Nov 17 15:01:28 2011 +0000
+++ b/tools/libxl/libxlutil.h Thu Nov 17 15:01:35 2011 +0000
@@ -58,6 +58,8 @@ int xlu_cfg_get_list(const XLU_Config*,
int *entries_r /* may be 0 */,
int dont_warn);
/* there is no need to free *list_r; lifetime is that of the XLU_Config */
+int xlu_cfg_get_list_as_string_list(const XLU_Config *cfg, const char *n,
+ libxl_string_list *sl, int dont_warn);
const char *xlu_cfg_get_listitem(const XLU_ConfigList*, int entry);
/* xlu_cfg_get_listitem cannot fail, except that if entry is
* out of range it returns 0 (not setting errno) */
diff -r 7d77e0269af7 -r 29d91e4d1f4f tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c Thu Nov 17 15:01:28 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c Thu Nov 17 15:01:35 2011 +0000
@@ -529,13 +529,6 @@ static void parse_config_data(const char
int pci_msitranslate = 1;
int e;
- XLU_ConfigList *dmargs;
- int nr_dmargs = 0;
- XLU_ConfigList *dmargs_hvm;
- int nr_dmargs_hvm = 0;
- XLU_ConfigList *dmargs_pv;
- int nr_dmargs_pv = 0;
-
libxl_domain_create_info *c_info = &d_config->c_info;
libxl_domain_build_info *b_info = &d_config->b_info;
@@ -1089,19 +1082,14 @@ skip_vfb:
if (!xlu_cfg_get_long (config,
"device_model_stubdomain_override", &l, 0))
dm_info->device_model_stubdomain = l;
-#define parse_extra_args(type) \
- if (!xlu_cfg_get_list(config, "device_model_args"#type,
\
- &dmargs##type, &nr_dmargs##type, 0))
\
- { \
- int i; \
- dm_info->extra##type = \
- xmalloc(sizeof(char*)*(nr_dmargs##type + 1)); \
- dm_info->extra##type[nr_dmargs##type] = NULL; \
- for (i=0; i<nr_dmargs##type; i++) { \
- const char *a = xlu_cfg_get_listitem(dmargs##type, i); \
- dm_info->extra##type[i] = a ? strdup(a) : NULL; \
- } \
- } \
+#define parse_extra_args(type) \
+ e = xlu_cfg_get_list_as_string_list(config,
"device_model_args"#type, \
+ &dm_info->extra##type, 0);
\
+ if (e && e != ESRCH) {
\
+ fprintf(stderr,"xl: Unable to parse
device_model_args"#type".\n");\
+ exit(-ERROR_FAIL); \
+ }
+
/* parse extra args for qemu, common to both pv, hvm */
parse_extra_args();
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:02 UTC
[Xen-devel] [PATCH 16 of 17] xl: make bootloader_args a list
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321542097 0
# Node ID bd514e08c509dd62a1db26318782ab37646788f5
# Parent 29d91e4d1f4f8d9233014b616547a9aed53b1515
xl: make bootloader_args a list
This is much more natural. Continue to support the old syntax in xl but
deprecate it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r 29d91e4d1f4f -r bd514e08c509 docs/man/xl.cfg.pod.5
--- a/docs/man/xl.cfg.pod.5 Thu Nov 17 15:01:35 2011 +0000
+++ b/docs/man/xl.cfg.pod.5 Thu Nov 17 15:01:37 2011 +0000
@@ -321,10 +321,11 @@ Run C<PROGRAM> to find the kernel image
C<PROGRAM> would be C<pygrub>, which is an emulation of
grub/grub2/syslinux.
-=item B<bootloader_args=STRING>
+=item B<bootloader_args=[ "ARG", "ARG", ...]>
-Append B<STRING> (split into words at whitespace) to the arguments to
-the B<bootloader> program. XXX this should be a list of strings.
+Append B<ARGs to the arguments to the B<bootloader>
+program. Alternatively if the argument is a simple string then it will
+be split into words at whitespace (this second option is deprecated).
=item B<root="STRING">
diff -r 29d91e4d1f4f -r bd514e08c509 tools/libxl/libxl_bootloader.c
--- a/tools/libxl/libxl_bootloader.c Thu Nov 17 15:01:35 2011 +0000
+++ b/tools/libxl/libxl_bootloader.c Thu Nov 17 15:01:37 2011 +0000
@@ -58,13 +58,9 @@ static char **make_bootloader_args(libxl
flexarray_set(args, nr++, libxl__sprintf(gc,
"--output-directory=%s", "/var/run/libxl/"));
if (info->u.pv.bootloader_args) {
- char *saveptr;
- /* Operate on a duplicate since strtok modifes the argument */
- char *dup = libxl__strdup(gc, info->u.pv.bootloader_args);
- char *t = strtok_r(dup, " \t\n", &saveptr);
- do {
- flexarray_set(args, nr++, t);
- } while ((t = strtok_r(NULL, " \t\n", &saveptr)));
+ char *p = info->u.pv.bootloader_args[0];
+ while (*(p++))
+ flexarray_set(args, nr++, p);
}
flexarray_set(args, nr++, disk);
diff -r 29d91e4d1f4f -r bd514e08c509 tools/libxl/libxl_types.idl
--- a/tools/libxl/libxl_types.idl Thu Nov 17 15:01:35 2011 +0000
+++ b/tools/libxl/libxl_types.idl Thu Nov 17 15:01:37 2011 +0000
@@ -185,7 +185,7 @@ libxl_domain_build_info = Struct("domain
("pv", Struct(None, [("kernel",
libxl_file_reference),
("slack_memkb", uint32),
("bootloader", string),
- ("bootloader_args", string),
+ ("bootloader_args",
libxl_string_list),
("cmdline", string),
("ramdisk",
libxl_file_reference),
("features", string, True),
diff -r 29d91e4d1f4f -r bd514e08c509 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c Thu Nov 17 15:01:35 2011 +0000
+++ b/tools/libxl/xl_cmdimpl.c Thu Nov 17 15:01:37 2011 +0000
@@ -334,9 +334,14 @@ static void printf_info(int domid,
printf("\t(nomigrate %d)\n", b_info->disable_migrate);
if (c_info->type == LIBXL_DOMAIN_TYPE_PV &&
b_info->u.pv.bootloader) {
+ int i;
printf("\t(bootloader %s)\n", b_info->u.pv.bootloader);
- if (b_info->u.pv.bootloader_args)
- printf("\t(bootloader_args %s)\n",
b_info->u.pv.bootloader_args);
+ if (b_info->u.pv.bootloader_args) {
+ printf("\t(bootloader_args");
+ for (i=0; b_info->u.pv.bootloader_args[i]; i++)
+ printf(" %s", b_info->u.pv.bootloader_args[i]);
+ printf(")\n");
+ }
}
printf("\t(image\n");
@@ -515,6 +520,51 @@ static void parse_disk_config(XLU_Config
parse_disk_config_multistring(config, 1, &spec, disk);
}
+static void split_string_into_string_list(const char *str,
+ const char *delim,
+ libxl_string_list *psl)
+{
+ char *s, *saveptr;
+ const char *p;
+ libxl_string_list sl;
+
+ int i = 0, nr = 0;
+
+ s = strdup(str);
+ if (s == NULL) {
+ fprintf(stderr, "unable to allocate memory to parse bootloader
args\n");
+ exit(-1);
+ }
+
+ /* Count number of entries */
+ p = strtok_r(s, delim, &saveptr);
+ do {
+ nr++;
+ } while ((p = strtok_r(NULL, delim, &saveptr)));
+
+ free(s);
+
+ s = strdup(str);
+
+ sl = malloc((nr+1) * sizeof (char *));
+ if (sl == NULL) {
+ fprintf(stderr, "unable to allocate memory for bootloader
args\n");
+ exit(-1);
+ }
+
+ p = strtok_r(s, delim, &saveptr);
+ do {
+ assert(i < nr);
+ sl[i] = strdup(p);
+ i++;
+ } while ((p = strtok_r(NULL, delim, &saveptr)));
+ sl[i] = NULL;
+
+ *psl = sl;
+
+ free(s);
+}
+
static void parse_config_data(const char *configfile_filename_report,
const char *configfile_data,
int configfile_len,
@@ -735,10 +785,26 @@ static void parse_config_data(const char
exit(1);
}
- xlu_cfg_replace_string (config, "bootloader",
- &b_info->u.pv.bootloader, 0);
- xlu_cfg_replace_string (config, "bootloader_args",
- &b_info->u.pv.bootloader_args, 0);
+ xlu_cfg_replace_string (config, "bootloader",
&b_info->u.pv.bootloader, 0);
+ switch (xlu_cfg_get_list_as_string_list(config,
"bootloader_args",
+
&b_info->u.pv.bootloader_args, 1))
+ {
+
+ case 0: break; /* Success */
+ case ESRCH: break; /* Option not present */
+ case EINVAL:
+ if (!xlu_cfg_get_string(config, "bootloader_args",
&buf, 0)) {
+
+ fprintf(stderr, "WARNING: Specifying
\"bootloader_args\" as a string is deprecated. "
+ "Please use a list of arguments.\n");
+ split_string_into_string_list(buf, " \t\n",
+
&b_info->u.pv.bootloader_args);
+ }
+ break;
+ default:
+ fprintf(stderr,"xl: Unable to parse bootloader_args.\n");
+ exit(-ERROR_FAIL);
+ }
if (!b_info->u.pv.bootloader &&
!b_info->u.pv.kernel.path) {
fprintf(stderr, "Neither kernel nor bootloader
specified\n");
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2011-Nov-17 15:02 UTC
[Xen-devel] [PATCH 17 of 17] docs: install txt files as html
# HG changeset patch # User Ian Campbell <ian.campbell@citrix.com> # Date 1321542098 0 # Node ID 83fc69637135353021aaacc96ded8fbbad1a4244 # Parent bd514e08c509dd62a1db26318782ab37646788f5 docs: install txt files as html A browser will display them just fine. NB: I''m not totally sure about this since many of the *.txt docs are out of date or deeply technical etc. It might be preferable to simply add the minimal necessary markdown to the ones we actually want to publish. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff -r bd514e08c509 -r 83fc69637135 docs/INDEX --- a/docs/INDEX Thu Nov 17 15:01:37 2011 +0000 +++ b/docs/INDEX Thu Nov 17 15:01:38 2011 +0000 @@ -1,5 +1,7 @@ misc/hvm-emulated-unplug Xen HVM emulated device unplug protocol +misc/console.txt Xen PV Console notes + # These are not all that useful anymore, hide them from the index reference/interface/index NO-INDEX reference/user/index NO-INDEX diff -r bd514e08c509 -r 83fc69637135 docs/Makefile --- a/docs/Makefile Thu Nov 17 15:01:37 2011 +0000 +++ b/docs/Makefile Thu Nov 17 15:01:38 2011 +0000 @@ -17,7 +17,8 @@ DOC_PDF := $(patsubst src/%.tex,pdf/%.p DOC_HTML := $(patsubst src/%.tex,html/reference/%/index.html,$(DOC_TEX)) \ $(patsubst %.markdown,html/%.html,$(DOC_MARKDOWN)) \ $(patsubst man/%.pod.1,html/man/%.1.html,$(DOC_MAN1SRC)) \ - $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC)) + $(patsubst man/%.pod.5,html/man/%.5.html,$(DOC_MAN5SRC)) \ + $(patsubst %.txt,html/%.txt,$(wildcard misc/*.txt)) DOC_TXT := $(patsubst %.txt,txt/%.txt,$(wildcard misc/*.txt)) \ $(patsubst %.markdown,txt/%.txt,$(DOC_MARKDOWN)) \ $(patsubst man/%.pod.1,txt/man/%.1.txt,$(DOC_MAN1SRC)) \ @@ -138,6 +139,10 @@ html/%.html: %.markdown $(MARKDOWN) $< > $@ ; else \ echo "markdown not installed; skipping $*.html."; fi +html/%.txt: %.txt + @$(INSTALL_DIR) $(@D) + cp $< $@ + html/man/%.1.html: man/%.pod.1 Makefile $(INSTALL_DIR) $(@D) $(POD2HTML) --infile=$< --outfile=$@ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2011-Nov-24 17:06 UTC
Re: [PATCH 07 of 17] docs: generate docs direct into final filename
Ian Campbell writes ("[Xen-devel] [PATCH 07 of 17] docs: generate docs
direct into final filename"):> docs: generate docs direct into final filename
>
> Nothing depends on the final document
... except the user.
> so there is not much point in generating
> to a tempfile and move-if-changed.
We don''t want to leave half-generated documents lying around which
aren''t fixed by "make", regardless of further dependencies,
surely ?
Ian.
Ian Campbell writes ("[Xen-devel] [PATCH 17 of 17] docs: install txt files
as html"):> docs: install txt files as html
...> NB: I''m not totally sure about this since many of the *.txt docs
are out of
> date or deeply technical etc. It might be preferable to simply add the
minimal
> necessary markdown to the ones we actually want to publish.
I think putting them all there is a reasonable first step.
Ian.
Ian Campbell
2011-Nov-24 17:12 UTC
Re: [PATCH 07 of 17] docs: generate docs direct into final filename
On Thu, 2011-11-24 at 17:06 +0000, Ian Jackson wrote:> Ian Campbell writes ("[Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final filename"): > > docs: generate docs direct into final filename > > > > Nothing depends on the final document > > ... except the user.OK, nothing about the build depends...> > so there is not much point in generating > > to a tempfile and move-if-changed. > > We don''t want to leave half-generated documents lying around which > aren''t fixed by "make", regardless of further dependencies, surely ?Doesn''t make automatically delete the targets if the command fails? Ian.
Ian Jackson
2011-Nov-24 17:25 UTC
Re: [PATCH 07 of 17] docs: generate docs direct into final filename
Ian Campbell writes ("Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs
direct into final filename"):> On Thu, 2011-11-24 at 17:06 +0000, Ian Jackson wrote:
> > We don''t want to leave half-generated documents lying around
which
> > aren''t fixed by "make", regardless of further
dependencies, surely ?
>
> Doesn''t make automatically delete the targets if the command
fails?
Crash-only software. Or in other words, to write reliable software,
do not rely on actions which are supposed to happen on error cleanup
or exit.
Ian.
Ian Campbell
2011-Nov-24 17:35 UTC
Re: [PATCH 07 of 17] docs: generate docs direct into final filename
On Thu, 2011-11-24 at 17:25 +0000, Ian Jackson wrote:> Ian Campbell writes ("Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final filename"): > > On Thu, 2011-11-24 at 17:06 +0000, Ian Jackson wrote: > > > We don''t want to leave half-generated documents lying around which > > > aren''t fixed by "make", regardless of further dependencies, surely ? > > > > Doesn''t make automatically delete the targets if the command fails? > > Crash-only software. Or in other words, to write reliable software, > do not rely on actions which are supposed to happen on error cleanup > or exit.Also, my experiments suggest that make doesn''t do this anyway (perhaps it''s only for implicit intermediaries or something). Do you want to pickup what you can from this series having dropped this patch and I''ll repost the rest or shall I just repost the whole lot? Ian.
Ian Jackson
2011-Nov-24 17:42 UTC
Re: [PATCH 13 of 17] docs: generate an index for the html output
Ian Campbell writes ("[Xen-devel] [PATCH 13 of 17] docs: generate an index
for the html output"):> docs: generate an index for the html output
>
> nb: I''m not a Perl wizard...
The Perl looks reasonable in general, except that some of the style is
a bit odd. perlstyle(1) is mostly a good guide.
In particular
> +sub write_file ($$) {
^
vs.
> +sub make_page($$$) {
^
perlsub(1) suggests inculding the space in Perl sub prototypes.
(Multiple occurrences.)
> + $l =~ s/.(html)$//g;
Why the capturing parens ?
> + if ( $title eq "" )
> + {
Brace should be on the same line.
> + $title = $h1 = "Xen Documentation";
And indent should be 4, not 1. (Multiple occurrences.)
> + print STDERR "Writing: $file\n";
> + write_file($file, $o);
Perhaps (i) the print should be to STDOUT (ii) it should be in
write_file ?
> +sub read_index
> +{
Missing prototype and bracket should be on same line. To make the
prototype work you''ll probably have to move the definition to before
the option parser call (or have a declaration). Perhaps the main
program should be at the bottom.
> + s/#.*$//;
This of course prevents link anchor texts in the inde including #,
which is probably an error which it would be nice to sort out now
rather than in the future when we''ll have to read this script to make
it cope.
> + m/([^\t]+)\t+(.*)/ or die;
This reliance on hard tabs will irritate many people. You should use
\S and \s. The filenames (the LHS) won''t contain whitespace of
course.
Also you probably meant to anchor the pattern. I would do something
like:
s/^\s+//;
s/\s+$//;
next if m/^\#/;
next unless m/\S/;
m/^(\S+)\s+(\S.*)$/ or die;
> +for (@docs) { s,^${outdir}/,, }
This is not correct because $outdir is not a regular expression. The
shortest way of doing this is indeed substr.
> +my $top = '''';
> +
> +foreach my $od (sort { $a cmp $b } uniq map { dirname($_) } @docs) {
> + my @d = (grep /^$od/, @docs);
Again, directory names are not regexps.
Do we really want an index per subdirectory ?
> + if ( $#d == 0 and $d[0] eq "$od/index.html" )
$#d==0 is a rather odd way of putting it. I would write @d==1.
> + $top .= "<li><a
href=\"${od}/index.html\">$od</a></li>\n";
> + $top .= "<ul>\n";
> + $top .= make_links($od,0,@d);
> + $top .= "</ul>\n";
Maybe this wants a here document ?
my $links = make_links blah blah;
$top .= <<END;
Ian.
Ian Campbell
2011-Nov-25 10:13 UTC
Re: [PATCH 13 of 17] docs: generate an index for the html output
On Thu, 2011-11-24 at 17:42 +0000, Ian Jackson wrote:> Ian Campbell writes ("[Xen-devel] [PATCH 13 of 17] docs: generate an index for the html output"): > > docs: generate an index for the html output > > > > nb: I''m not a Perl wizard... > > The Perl looks reasonable in general, except that some of the style is > a bit odd. perlstyle(1) is mostly a good guide.Thanks for the thorough review. I''ve trimmed everything I agree with and don''t have a comment on.> > + $l =~ s/.(html)$//g; > > Why the capturing parens ?I had intended to add "|txt" etc at some point. I suppose this ought to be (?:...) instead though.> > > + if ( $title eq "" ) > > + { > > Brace should be on the same line. > > > + $title = $h1 = "Xen Documentation"; > > And indent should be 4, not 1. (Multiple occurrences.)emacs seems to default to indentations of 4 spaces but unhelpfully turns two lots of that into a hard tab. I''ll figure out how to nix that behaviour.> > + s/#.*$//; > > This of course prevents link anchor texts in the inde including #, > which is probably an error which it would be nice to sort out now > rather than in the future when we''ll have to read this script to make > it cope.Looks like (in the suggested code below) requiring the # to be in the first column instead is your preferred solution here? Works for me.> Also you probably meant to anchor the pattern. I would do something > like: > > s/^\s+//; > s/\s+$//; > next if m/^\#/; > next unless m/\S/;I think that would be a syntax error so die unless m/\S/ ?> m/^(\S+)\s+(\S.*)$/ or die; > > > +for (@docs) { s,^${outdir}/,, } > > This is not correct because $outdir is not a regular expression. The > shortest way of doing this is indeed substr.OK. Aside: how does one dynamically construct a regex then?> Do we really want an index per subdirectory ?I was thinking of folks how manually type urls or who string the last element off. Having an index in each dir ensures they get something structured and not the apache generated thing. It does complicate the code though so I could be convinced to drop it. Ian.
Ian Campbell
2011-Nov-25 10:22 UTC
Re: [PATCH 07 of 17] docs: generate docs direct into final filename
On Thu, 2011-11-24 at 17:35 +0000, Ian Campbell wrote:> On Thu, 2011-11-24 at 17:25 +0000, Ian Jackson wrote: > > Ian Campbell writes ("Re: [Xen-devel] [PATCH 07 of 17] docs: generate docs direct into final filename"): > > > On Thu, 2011-11-24 at 17:06 +0000, Ian Jackson wrote: > > > > We don''t want to leave half-generated documents lying around which > > > > aren''t fixed by "make", regardless of further dependencies, surely ? > > > > > > Doesn''t make automatically delete the targets if the command fails? > > > > Crash-only software. Or in other words, to write reliable software, > > do not rely on actions which are supposed to happen on error cleanup > > or exit. > > Also, my experiments suggest that make doesn''t do this anyway (perhaps > it''s only for implicit intermediaries or something). > > Do you want to pickup what you can from this series having dropped this > patch and I''ll repost the rest or shall I just repost the whole lot?I needed to rebase so I could get to work on your comments to patch 13 so I may as well repost. Ian.
Roger Pau Monné
2011-Nov-25 11:22 UTC
Re: [PATCH 13 of 17] docs: generate an index for the html output
2011/11/17 Ian Campbell <ian.campbell@citrix.com>:> # HG changeset patch > # User Ian Campbell <ian.campbell@citrix.com> > # Date 1321542075 0 > # Node ID 8f2404eef8fac8020528b408b3a958d81cbb73c0 > # Parent c1f8406da50743cd0597b93c4b5b8b6ff03ede42 > docs: generate an index for the html output > > nb: I'm not a Perl wizard... > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com> > > diff -r c1f8406da507 -r 8f2404eef8fa docs/INDEX > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/docs/INDEX Thu Nov 17 15:01:15 2011 +0000 > @@ -0,0 +1,5 @@ > +misc/hvm-emulated-unplug Xen HVM emulated device unplug protocol > + > +# These are not all that useful anymore, hide them from the index > +interface/index NO-INDEX > +user/index NO-INDEX > diff -r c1f8406da507 -r 8f2404eef8fa docs/Makefile > --- a/docs/Makefile Thu Nov 17 14:54:38 2011 +0000 > +++ b/docs/Makefile Thu Nov 17 15:01:15 2011 +0000 > @@ -45,7 +45,7 @@ ps: $(DOC_PS) > pdf: $(DOC_PDF) > > .PHONY: html > -html: $(DOC_HTML) > +html: $(DOC_HTML) html/index.html > > .PHONY: txt > txt: $(DOC_TXT) > @@ -128,6 +128,9 @@ html/%/index.html: src/%.tex > $< 1>/dev/null 2>/dev/null ; else \ > echo "latex2html not installed; skipping $*."; fi > > +html/index.html: $(DOC_HTML) ./gen-html-index INDEX > + ./gen-html-index -i INDEX html $(DOC_HTML) > + > html/%.html: %.markdown > @$(INSTALL_DIR) $(@D) > @set -e ; if which $(MARKDOWN) 1>/dev/null 2>/dev/null; then \ > diff -r c1f8406da507 -r 8f2404eef8fa docs/gen-html-index > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/docs/gen-html-index Thu Nov 17 15:01:15 2011 +0000 > @@ -0,0 +1,129 @@ > +#!/usr/bin/perl -wPlease use "/usr/bin/env perl" or call the script from the Makefile with "perl ./..." (as Ian Jackson has done in his patch to import queue.h) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2011-Nov-25 12:22 UTC
Re: [PATCH 13 of 17] docs: generate an index for the html output
Ian Campbell writes ("Re: [Xen-devel] [PATCH 13 of 17] docs: generate an
index for the html output"):> On Thu, 2011-11-24 at 17:42 +0000, Ian Jackson wrote:
> > next unless m/\S/;
>
> I think that would be a syntax error so die unless m/\S/ ?
Surely ignoring blank lines is going to be less irritating.
> > This is not correct because $outdir is not a regular expression. The
> > shortest way of doing this is indeed substr.
>
> OK.
>
> Aside: how does one dynamically construct a regex then?
However you like. Make a variable which contains your regexp. If you
have a string in a scalar and want a regexp which matches that string
you can do this:
my $regexp = $string;
$regexp =~ s/\W/\\$&/g;
... m/^$regexp/ ...
> > Do we really want an index per subdirectory ?
>
> I was thinking of folks how manually type urls or who string the last
> element off. Having an index in each dir ensures they get something
> structured and not the apache generated thing.
True.
> It does complicate the code though so I could be convinced to drop it.
No, that''s OK.
Ian.
Ian Campbell
2011-Nov-25 13:36 UTC
Re: [PATCH 13 of 17] docs: generate an index for the html output
On Fri, 2011-11-25 at 12:22 +0000, Ian Jackson wrote:> Ian Campbell writes ("Re: [Xen-devel] [PATCH 13 of 17] docs: generate an index for the html output"): > > On Thu, 2011-11-24 at 17:42 +0000, Ian Jackson wrote: > > > next unless m/\S/; > > > > I think that would be a syntax error so die unless m/\S/ ? > > Surely ignoring blank lines is going to be less irritating.I missed that this was \S not \s. Your way does indeed make sense.> > > This is not correct because $outdir is not a regular expression. The > > > shortest way of doing this is indeed substr. > > > > OK. > > > > Aside: how does one dynamically construct a regex then? > > However you like. Make a variable which contains your regexp. If you > have a string in a scalar and want a regexp which matches that string > you can do this: > my $regexp = $string; > $regexp =~ s/\W/\\$&/g; > ... m/^$regexp/ ...Ah, I thought you were suggesting that /$something/ was not valid at all, but you meant only if you don''t correctly quote it etc. Thanks, Ian.> > > > Do we really want an index per subdirectory ? > > > > I was thinking of folks how manually type urls or who string the last > > element off. Having an index in each dir ensures they get something > > structured and not the apache generated thing. > > True. > > > It does complicate the code though so I could be convinced to drop it. > > No, that''s OK. > > Ian.
Ian Campbell
2011-Nov-25 14:02 UTC
Re: [PATCH 13 of 17] docs: generate an index for the html output
On Fri, 2011-11-25 at 11:22 +0000, Roger Pau Monné wrote:> 2011/11/17 Ian Campbell <ian.campbell@citrix.com>: > > +#!/usr/bin/perl -w > > Please use "/usr/bin/env perl" or call the script from the Makefile > with "perl ./..." (as Ian Jackson has done in his patch to import > queue.h)This doesn't allow the use of -w: /usr/bin/env: perl -w: No such file or directory It might be possible to achieve the same with $^W = 1? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Apparently Analagous Threads
- [PATCH] libxl: use named options for tsc_mode
- xl doesn't honour the parameter cpu_weight from my config file while xm does honour it
- xl doesn't honour the parameter cpu_weight from my config file while xm does honour it
- [PATCH] xl: remove duplicate line
- [PATCH] libxl: do not overwrite user supplied config when running bootloader