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.vivekanandarajah@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