On 09/12/2011 10:53 AM, Avi Kivity wrote:
On 09/12/2011 04:46 PM, Lucas Meneghel Rodrigues wrote:
Yes, that would also work, having different variants with different
qemu and qemu-img paths. Those binaries would have to be already
pre-built, but then we miss the ability autotest has of building the
binaries and prepare the environment. It'd be like:
variant1:
qemu = /path/to/qemu1
qemu-img = /path/to/qemu-img1
extra_params = "--appropriate --extra --params2"
variant2:
qemu = /path/to/qemu2
qemu-img = /path/to/qemu-img2
extra_params = "--appropriate --extra --params2"
Something like that. It's a feasible intermediate solution until I
finish work on supporting multiple userspaces.
Another option is, now that the binary name 'qemu' is available for
general use, make it possible to invoke everything with just one binary:
qemu -system -target mips ...
qemu-system -target mips ...
qemu-system-mips ...
are all equivalent. autotest should easily be able to pass different
-target based on the test being run.
Indeed, a good idea, although there are cases where we indeed want to
run different user spaces (say, a windows reactivation test for
example), so it's still worth to implement the multiple userspaces thing
for autotest. But in the case we just want to run multiple targets, this
would be very handy indeed.
