On 26/06/2018 16:35, Alex Bennée wrote:
> Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Pushed with a little bit of editing, thanks!
diff --git a/_posts/2018-06-21-tcg-testing.md b/_posts/2018-06-28-tcg-testing.md
similarity index 83%
rename from _posts/2018-06-21-tcg-testing.md
rename to _posts/2018-06-28-tcg-testing.md
index e61312e..026e726 100644
--- a/_posts/2018-06-21-tcg-testing.md
+++ b/_posts/2018-06-28-tcg-testing.md
@@ -7,39 +7,39 @@ author: Alex Bennée
categories: [testing, docker, compilation, tcg]
---
-Ever since I started working on QEMU there was a small directory
-called tests/tcg that was in a perpetually broken state. It contains
+Ever since I started working on QEMU, a small directory
+called `tests/tcg` has been in a perpetually broken state. It contains
tests that exercise QEMU's ability to work across architectures using
the power of the Tiny Code Generator. However as these tests needed to
be compiled for the *guest* architectures and not the *host*
-architecture - known as cross-compiling - most developers never ran
-them. As the tests were hardly ever built inevitably a certain amount
-of bit-rot set in.
+architecture—this is known as cross-compiling—most developers
+never ran them. As the tests were hardly ever built inevitably a certain
+amount of bit-rot set in.
# Cross Compilers
-In the old days cross-compilation setups were almost all hand-crafted
+In the old days, cross-compilation setups were almost all hand-crafted
affairs which involved building versions of binutils, gcc and a basic
-libc. If you couldn't get someone to give you a pre-built tarball it
+libc. If you couldn't get someone to give you a pre-built tarball, it
was something you laboured through once and hopefully never had to
touch again. There were even dedicated scripts like crosstool-ng which
attempted to make the process of patching and configuring your
toolchain easier.
While the distributions have improved their support for cross
-compilers over the years there are still plenty of variations in how
+compilers over the years, there are still plenty of variations in how
they are deployed. It is hard for a project like QEMU which has to
build on a wide range of operating systems and architectures to
seamlessly use any given distributions compiler setup. However for
-those with cross compilers to hand `configure` now accepts two
+those with cross compilers at hand `configure` now accepts two
additional flags:
--cross-cc-$(ARCH)
--cross-cc-flags-$(ARCH)
With a compiler specified for each guest architecture you want to test
-the build system can now build and run the tests. However for
-developers that don't have cross compilers around they can now take
+the build system can now build and run the tests. For
+developers that don't have cross compilers around, they can take
advantage of QEMU's docker images.
# Enter Docker Containers
@@ -66,11 +66,11 @@ instead of tracking down a piece of ARM hardware to
actually build on.
Run `make docker` in your source tree to see the range of builds and
tests it can support.
-# make check-tcg
+# `make check-tcg`
With the latest work [merged into
master](https://git.qemu.org/?p=qemu.git;a=commit;h=de44c044420d1139480fa50c2d5be19223391218)
we can now
-take advantage of both hand configured and docker based cross
+take advantage of either hand-configured and Docker-based cross
compilers to build test cases for TCG again. To run the TCG tests
after you have built QEMU:
@@ -79,16 +79,16 @@ after you have built QEMU:
and the build system will build and run all the tests it can for your
configured targets.
-# Rules for tests/tcg
+# Rules for `tests/tcg`
So now we have the infrastructure in place to add new tests what rules
need to be followed to add new tests?
-Well the first thing to note is currently all the tests are for
-linux-user versions of QEMU. This means the tests are all currently
+Well the first thing to note is currently all the tests are for the
+`linux-user` variant of QEMU. This means the tests are all currently
user-space tests that have access to the Linux syscall ABI.
-Another thing to note is the tests are standalone from the rest of the
+Another thing to note is the tests are separate from the rest of the
QEMU test infrastructure. To keep things simple they are compiled as
standalone "static" binaries. As the cross-compilation setup can be
quite rudimentary for some of the rarer architectures we only compile
@@ -99,10 +99,10 @@ glibc so shouldn't be a problem.
Finally when writing new tests consider if it really is architecture
specific or can be added to `tests/tcg/multiarch`. The multiarch tests
are re-built for every supported architecture and should be the
-default place for anything explicitly testing syscalls and other
+default place for anything that tests syscalls or other
common parts of the code base.
-# What's Next
+# What's next
My hope with this work is we can start adding more tests to
systematically defend functionality in linux-user. In fact I hope the
@@ -135,5 +135,3 @@ status over a simple serial link which will need to be
parsed and
handled in custom versions of the
[`run-%:`](https://git.qemu.org/?p=qemu.git;a=blob;f=tests/tcg/Makefile;h=bf064153900a438e4ad8e2d79eaaac8a27d66062;hb=HEAD#l95)
rule.
-
-
