Re: [Qemu-devel] [PATCH] blogposts: add post about the new check-tcg infrastructure

[Paolo Bonzini <pbonzini@redhat.com>]

On 26/06/2018 16:35, Alex Bennée wrote:
> Signed-off-by: Alex Bennée <alex.bennee@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&mdash;this is known as cross-compiling&mdash;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.
-
-