Thanks Riku! I was hoping that someone would point me to an existing implementation. I will check it out.
-- Maxim Kuvyrkov www.linaro.org On May 21, 2014, at 11:55 PM, Riku Voipio <riku.voi...@linaro.org> wrote: > 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
