On May 21, 2014, at 10:54 PM, Bernie Ogden bernie.ogden@linaro.org wrote:
If we add models as targets then that alleviates the sharing problem a bit - for test runs that aren't going to be too slow on models. And you'll need to watch out for nested '"' in $@, but I guess you know that.
The point is to run it primarily on real hardware. Binfmt_misc is already working nicely if you want to do cross-testing with QEMU.
I guess this approach is similar to what 'make check test-wrapper="...../glibc/scripts/cross-test-ssh.sh hostname"' is supposed to do for glibc. Ryan mentioned that glibc cross-test doesn't work, and it certainly fell over when I tried it. That makes me wonder whether there are hidden difficulties here, but that vague bit of evidence aside, the approach sounds sensible to me.
As Ryan mentioned, it all works, but is a pain to setup. And "yes" the idea is very similar with the main distinction of using kernel's binfmt_misc instead of explicit test-wrapper.
-- Maxim Kuvyrkov www.linaro.org
On 21 May 2014 07:46, Kugan kugan.vivekanandarajah@linaro.org wrote:
On 21/05/14 16:08, Maxim Kuvyrkov wrote:
I have been thinking how to simplify cross-testing our toolchain for both automated and development/debugging builds, and among various options the most universal I came up with is ARM hardware + ssh + binfmt_misc + sshfs. I wonder if anyone has already tried this or can suggest alternatives which are as universal.
Given:
- host x86_64 development machine
- cross-compiler
- target hardware with fast network to the host
- host and target have ssh
- testsuite (gcc/glibc/gdb/etc)
Here is how it is going to work
- On host we create a simple wrapper script that will pass through its arguments as command to execute on target via ssh:
=== #!/bin/sh ssh -p 22NN $TARGET_BOARD "$@" ===
We register this script in binfmt_misc to be used as interpreter for target binaries. Value of $TARGET_BOARD will be picked up from the environment and can be set to different boards for different testsuite runs.
The target board needs to be prepared for a particular testsuite run:
-- Runtime libraries need to be either copied or mounted via sshfs from the host. It is an open question how best to install several sets of libraries (for parallel runs) so that each set appears to be main system libraries. My current thinking is a separate ssh server inside chroot per each test run. -- Test directory needs to be sshfs mounted on target from host so that the target could see test executables. -- Preparation/finalization of the board can either be done explicitly before/after testing. Or it can be done on demand by the aforementioned script: the script checks whether a multiplexed ssh socket exists, and, if not, it prepares the board and starts a multiplexed ssh connection.
Is this set-up for NX? Issue is how do we share the target board between different users? We can of-course initiate a lava hacking session but the amount of time we will have to wait to get the session active might be too long depending on the target classes availability.
Thanks Kugan
- Testing is fired up as if it is normal "native" testing. Whenever kernel is given an ARM binary to execute -- it passes it off to wrapper, which passes it off to the target board via ssh. The board sees same filesystem as host and happily executes binaries against toolchain runtime libraries.
Comments or rotten tomatoes?
Thank you,
-- Maxim Kuvyrkov www.linaro.org
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain