Add the QEMU test invocation to make test
#199
Conversation
Currently we use Alistair's fork of QEMU, as it has patches for HiFive support that upstream QEMU doesn't have. QEMU is installed into a `build/` directory that is in .gitignore so it doesn't touch the host system or dirty the repository.
…that kernel. Move QEMU tests to `make test` from the Travis config. I also fixed an issue in test-runner where it breaks console echo. I don't fully understand why, but I needed to set QEMU's stdin to null rather than test-runner's stdin to avoid breaking console echo. This should fix tock#198
Previously, QEMU's build in Travis was run with -j8. Now QEMU is built by `make setup`, so we should pass `-j8` to `make setup` instead.
I also switched to using `cargo clean` in the Makefile rather than manually removing `target/` and `Cargo.lock`, as that seems like a more correct and maintainable design.
|
I am a bit sceptical about adding test dependencies as git submodules. In my opinion git submoudules should be ultima ratio even for compile time dependencies. My favorite solution would be to publish binary releases of the kernel and retrieve them during the CI of tock. This would speed up the CI a lot. |
Putting Tock into a submodule makes it easier to contribute. If someone needs to test libtock-rs with a newer Tock version, they can update the Tock submodule to that version very easily. If someone wants to modify Tock (e.g. to add a new syscall API) and test it with libtock-rs, they can easily do so by making those changes in the submodule. The submodule can be pointed at their fork of Tock. On my Chromebook (which is far from the fastest machine around), it takes 17.4 seconds to build the Tock kernel. If I don't change the |
The issue here is not local build time, I am worried about the build times in CI which are much longer due to do limited resources. However, this particular PR does not change the fact that we check out and build the tock kernel in every build so my argument doesn't hold. I am not sure to which extend we should prepare a "working environment" for a developer but if the benefits of having the kernel as a submodule outweighs the risks (complexity, coupling of the kernel to the userspace library) I am okay with doing so. One little remark: I would probably give a hint to the users of the library that there are submodules to be initialized. bors d+ |
|
✌️ jrvanwhy can now approve this pull request. To approve and merge a pull request, simply reply with |
|
I changed the |
|
bors r+ |
|
Build succeeded: |
Prior to this PR, there was no easy way to run
libtock_testin QEMU. It was run as part of the Travis CI checks, but notmake test. This PR moves that functionality into the Makefile, so thatmake testruns the QEMU tests.Main changes in this PR:
make setup-qemu, automatically run as part ofmake qemu, which compiles QEMU in a newbuilddirectory. This shouldn't touch the host system, although you need QEMU's dependencies for it to succeed.test-runnerto use the QEMU and Tock kernel built bymake setup-qemuandmake kernel-hifive.test-qemu-hifiveto runlibtock_teston an emulated hifive.test-qemu-hifiveas a dependency oftestso thatmake testruns both sets of testsmake exampleswith a dependency on the examples, so that running parallel make jobs works correctly.