@@ -64,7 +64,7 @@ Topology
The following figure shows the basic structure of the 9pfs
implementation in QEMU.
-`frameless|upright=3.0 <File:9pfs_topology.png>`__
+.. image:: img/9pfs_topology.png
The implementation consists of 3 modular components: 9p server, 9p
filesystem drivers and 9p transport drivers. The 9p client on guest OS
@@ -219,7 +219,7 @@ Another important aspect to know is that once a thread leaves the scope
of a Coroutine, then that thread is back at using its own thread-owned
stack again.
-`frameless|upright=2.4 <File:Coroutines_stacks.png>`__
+.. image:: img/Coroutines_stacks.png
Each coroutine instance usually handles a certain "collaborative" task,
where "collaborative" means that individual parts of the task usually
@@ -253,7 +253,7 @@ Control Flow
The following figure shows the control flow and relationship of Threads
and Coroutines of the 9pfs implementation.
-`frameless|upright=3.5 <File:9pfs_control_flow.png>`__
+.. image:: img/9pfs_control_flow.png
Getting back to 9pfs as concrete user of Coroutines, every 9P client
request that comes in on 9P server side is a task the 9P server needs to
The original source https://wiki.qemu.org/Documentation/9p does not use a prefixed path for pictures. The (auto converted) in-tree .rst version of the 9p documentation though uses pictures that are placed into the subdirectory 'img' for not mixing them with .rst files within the same directory, so prefix references to those pictures with 'img/'. Also the auto conversion tool 'pandoc' did not replace the image references by a correct 'image' rst keyword, so correct that as well. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> --- docs/devel/9p.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)