[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] template for a script for running an ad-hoc QEMU image
From: |
Peter Maydell |
Subject: |
[Qemu-devel] template for a script for running an ad-hoc QEMU image |
Date: |
Fri, 26 Oct 2018 22:21:58 +0100 |
In a conversation this week I mentioned the scripts I use for running
ad-hoc QEMU guest images that I have. The idea here is just that
by making sure that whenever I get a test image I set it up to be
run in the same way, I don't have the problem of trying to remember
how to run the guest if I come back to it after six months.
Here's an example -- I generally just copy-paste-and-edit an older
script when I get a new test image.
============
#!/bin/sh -e
TESTDIR="$(cd "$(dirname "$0")"; pwd)"
QEMU="$@"
${QEMU} -M lm3s6965evb -kernel "${TESTDIR}"/qs_ek-lm3s6965.bin
============
I put each guest image in its own directory, and the script is
always named "runme" and is executable. Then any test can be run with
path/to/test/runme path/to/qemu-system-whatever
There's no magic here but there are a couple of nice nuances here:
* the rune at the top sets TESTDIR to the directory containing the
script, regardless of what the current working directory is when
you run the script; references to kernels, disk files, etc should
then all use $TESTDIR rather than being absolute or relative paths
* the use of $@ means you can also do
path/to/test/runme gdb --args path/to/qemu-system-whatever
path/to/test/runme valgrind path/to/qemu-system-whatever
and other similar things.
This doesn't fix any of the problems of using ad-hoc human-run
images for testing, but at least it makes them all be runnable in
the same way, reducing the barrier to randomly running one of them.
thanks
-- PMM
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] template for a script for running an ad-hoc QEMU image,
Peter Maydell <=