Hi, This is essentially what sbrsh was created for a decade ago:
http://www.scratchbox.org/documentation/user/scratchbox-1.0/html/sbrsh.html http://packages.qa.debian.org/s/sbrsh.html You run register sbrsh with binfmt-misc (or just prefix sbrsh command) and run sbrshd on the target device. You have a configuration file for sbrsh that tells what to mount from where. Haven't used it for a long long time... Riku On 21 May 2014 09:08, Maxim Kuvyrkov <maxim.kuvyr...@linaro.org> 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. > > 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
