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
