On Wed, May 21, 2014 at 5:54 AM, Bernie Ogden bernie.ogden@linaro.orgwrote:
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.
Ultimately we need to validate on real hardware. From a release perspective it's necessary. From a development perspective being able to validate with models is effective until you need to have the final validation.
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.
It's not that it doesn't work. It's just that it's complicated to setup because it involves setting up a network file system.
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
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain