On Wed, May 21, 2014 at 5:54 AM, Bernie Ogden <bernie.og...@linaro.org>wrote:
> 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.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 > -- Ryan S. Arnold Linaro Toolchain Working Group - Engineering Manager www.linaro.org
_______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain