[gnome-continuous-yocto/gnomeostree-3.28-rocko: 6900/8267] dev-manual, ref-manual: Eliminated pre-built section
- From: Emmanuele Bassi <ebassi src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gnome-continuous-yocto/gnomeostree-3.28-rocko: 6900/8267] dev-manual, ref-manual: Eliminated pre-built section
- Date: Sun, 17 Dec 2017 05:29:37 +0000 (UTC)
commit 15901164ee71dec0906dadaff08f3365a66feb05
Author: Scott Rifenbark <srifenbark gmail com>
Date: Tue Jul 18 10:44:37 2017 -0700
dev-manual, ref-manual: Eliminated pre-built section
Fixes [YOCTO #11630]
I took the section that described how to use a pre-built kernel
and run it through QEMU out. This is basically a QEMU usage
section and is not in that area. There were some QEMU speed
up items suitable for the QEMU concepts section in the ref-manual.
I put those in that area.
(From yocto-docs rev: b081013aa10b42e4eb88ed54940112c5ae106911)
Signed-off-by: Scott Rifenbark <srifenbark gmail com>
Signed-off-by: Richard Purdie <richard purdie linuxfoundation org>
documentation/dev-manual/dev-manual-start.xml | 59 +------------------
documentation/ref-manual/usingpoky.xml | 78 +++++++++++++++++++++++++
2 files changed, 80 insertions(+), 57 deletions(-)
---
diff --git a/documentation/dev-manual/dev-manual-start.xml b/documentation/dev-manual/dev-manual-start.xml
index 0835650..e70d79e 100644
--- a/documentation/dev-manual/dev-manual-start.xml
+++ b/documentation/dev-manual/dev-manual-start.xml
@@ -858,6 +858,7 @@
</para>
</section>
+<!--
<section id='using-pre-built-binaries-and-qemu'>
<title>Using Pre-Built Binaries and QEMU</title>
@@ -906,64 +907,8 @@
"<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
section.
</para>
-
- <para>
- Using QEMU to emulate your hardware can result in speed issues
- depending on the target and host architecture mix.
- For example, using the <filename>qemux86</filename> image in the emulator
- on an Intel-based 32-bit (x86) host machine is fast because the target and
- host architectures match.
- On the other hand, using the <filename>qemuarm</filename> image on the same Intel-based
- host can be slower.
- But, you still achieve faithful emulation of ARM-specific issues.
- </para>
-
- <para>
- To speed things up, the QEMU images support using <filename>distcc</filename>
- to call a cross-compiler outside the emulated system.
- If you used <filename>runqemu</filename> to start QEMU, and the
- <filename>distccd</filename> application is present on the host system, any
- BitBake cross-compiling toolchain available from the build system is automatically
- used from within QEMU simply by calling <filename>distcc</filename>.
- You can accomplish this by defining the cross-compiler variable
- (e.g. <filename>export CC="distcc"</filename>).
- Alternatively, if you are using a suitable SDK image or the appropriate
- stand-alone toolchain is present,
- the toolchain is also automatically used.
- </para>
-
- <note>
- Several mechanisms exist that let you connect to the system running on the
- QEMU emulator:
- <itemizedlist>
- <listitem><para>QEMU provides a framebuffer interface that makes standard
- consoles available.</para></listitem>
- <listitem><para>Generally, headless embedded devices have a serial port.
- If so, you can configure the operating system of the running image
- to use that port to run a console.
- The connection uses standard IP networking.</para></listitem>
- <listitem><para>
- SSH servers exist in some QEMU images.
- The <filename>core-image-sato</filename> QEMU image has a
- Dropbear secure shell (SSH) server that runs with the root
- password disabled.
- The <filename>core-image-full-cmdline</filename> and
- <filename>core-image-lsb</filename> QEMU images
- have OpenSSH instead of Dropbear.
- Including these SSH servers allow you to use standard
- <filename>ssh</filename> and <filename>scp</filename> commands.
- The <filename>core-image-minimal</filename> QEMU image,
- however, contains no SSH server.
- </para></listitem>
- <listitem><para>You can use a provided, user-space NFS server to boot the QEMU session
- using a local copy of the root filesystem on the host.
- In order to make this connection, you must extract a root filesystem tarball by using the
- <filename>runqemu-extract-sdk</filename> command.
- After running the command, you must then point the <filename>runqemu</filename>
- script to the extracted directory instead of a root filesystem image file.</para></listitem>
- </itemizedlist>
- </note>
</section>
+-->
</chapter>
<!--
vim: expandtab tw=80 ts=4
diff --git a/documentation/ref-manual/usingpoky.xml b/documentation/ref-manual/usingpoky.xml
index 2f5316d..c323d38 100644
--- a/documentation/ref-manual/usingpoky.xml
+++ b/documentation/ref-manual/usingpoky.xml
@@ -1111,6 +1111,84 @@
</para>
</section>
+ <section id='qemu-performance'>
+ <title>QEMU Performance</title>
+
+ <para>
+ Using QEMU to emulate your hardware can result in speed issues
+ depending on the target and host architecture mix.
+ For example, using the <filename>qemux86</filename> image in the
+ emulator on an Intel-based 32-bit (x86) host machine is fast
+ because the target and host architectures match.
+ On the other hand, using the <filename>qemuarm</filename> image
+ on the same Intel-based host can be slower.
+ But, you still achieve faithful emulation of ARM-specific issues.
+ </para>
+
+ <para>
+ To speed things up, the QEMU images support using
+ <filename>distcc</filename> to call a cross-compiler outside the
+ emulated system.
+ If you used <filename>runqemu</filename> to start QEMU, and the
+ <filename>distccd</filename> application is present on the host
+ system, any BitBake cross-compiling toolchain available from the
+ build system is automatically used from within QEMU simply by
+ calling <filename>distcc</filename>.
+ You can accomplish this by defining the cross-compiler variable
+ (e.g. <filename>export CC="distcc"</filename>).
+ Alternatively, if you are using a suitable SDK image or the
+ appropriate stand-alone toolchain is present, the toolchain is
+ also automatically used.
+ </para>
+
+ <note>
+ Several mechanisms exist that let you connect to the system
+ running on the QEMU emulator:
+ <itemizedlist>
+ <listitem><para>
+ QEMU provides a framebuffer interface that makes standard
+ consoles available.
+ </para></listitem>
+ <listitem><para>
+ Generally, headless embedded devices have a serial port.
+ If so, you can configure the operating system of the
+ running image to use that port to run a console.
+ The connection uses standard IP networking.
+ </para></listitem>
+ <listitem><para>
+ SSH servers exist in some QEMU images.
+ The <filename>core-image-sato</filename> QEMU image has a
+ Dropbear secure shell (SSH) server that runs with the root
+ password disabled.
+ The <filename>core-image-full-cmdline</filename> and
+ <filename>core-image-lsb</filename> QEMU images
+ have OpenSSH instead of Dropbear.
+ Including these SSH servers allow you to use standard
+ <filename>ssh</filename> and <filename>scp</filename>
+ commands.
+ The <filename>core-image-minimal</filename> QEMU image,
+ however, contains no SSH server.
+ </para></listitem>
+ <listitem><para>
+ You can use a provided, user-space NFS server to boot
+ the QEMU session using a local copy of the root
+ filesystem on the host.
+ In order to make this connection, you must extract a
+ root filesystem tarball by using the
+ <filename>runqemu-extract-sdk</filename> command.
+ After running the command, you must then point the
+ <filename>runqemu</filename>
+ script to the extracted directory instead of a root
+ filesystem image file.
+ See the
+ "<ulink
url='&YOCTO_DOCS_DEV_URL;#qemu-running-under-a-network-file-system-nfs-server'>Running Under a Network File
System (NFS) Server</ulink>"
+ section in the Yocto Project Development Manual for more
+ information.
+ </para></listitem>
+ </itemizedlist>
+ </note>
+ </section>
+
<section id='qemu-command-line-syntax'>
<title>QEMU Command-Line Syntax</title>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]