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.
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. On 21 May 2014 07:46, Kugan <kugan.vivekanandara...@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 >> >> 1. 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 "$@" >> === >> >> 2. 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. >> >> 3. 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 > >> 4. 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
