From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hms365.onmicrosoft.com; s=selector1-hms-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aEAAYtsXYesQ1OEip7zWjBYF39RDt1dtKl5vwOcztpA=; b=kzSUJHpbUc/InSMzq8GBsnGbfUgM9d8Yn6e67xjpN3VR0zSqLimxiTswzz8kzOU5RgKVjqQtFgNOSWSVMDAXLy+vD2kJ9imHE465+TCRoc4FH2hFHZpgZEx1+037HNl8Nt4c9AvFHyOdZS1WJD19Uwzvex621gLE0n5rFhZR0Bk= From: Rafael Gago Castano Date: Fri, 12 May 2017 09:38:47 +0000 Message-ID: References: , , , In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Fuego] First steps with fuego List-Id: Mailing list for the Fuego test framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Bird, Timothy" Cc: "fuego@lists.linuxfoundation.org" For some reason I didn't CC the previous mail to the mailing list but just = to you. > OK.=A0 cmd *should* return the error code from the remote command. >=A0If it's not, then that's a bug. Yes, I was in a rush yesterday and I had no time to do the things properly,= but I wrote a terse loop with while using "test -f" to poll for file exist= ance on the DUT and it failed, so I wronlgy assumed that was a "cmd" error. If I write this in the body of a test, the test gets early interrupted and = never prints "after" (I'm using the ssh transport): echo "before" cmd "test -f /tmp/nonexistant-file" echo "after" On the logs I see: ++ echo before before ++ cmd 'test -f /tmp/nonexistant' ++ report_devlog 'cmd: test -f /tmp/nonexistant' ++ echo 'cmd: test -f /tmp/nonexistant' ++ ov_transport_cmd 'test -f /tmp/nonexistant' ++ case "$TRANSPORT" in ++ sshpass -e ssh -o ServerAliveInterval=3D30 -o StrictHostKeyChecking=3Dno= -o UserKnownHostsFile=3D/dev/null -o ConnectTimeout=3D30 -p 22 root@192.16= 8.1.2 'test -f /tmp/nonexistant' Warning: Permanently added '192.168.1.2' (ECDSA) to the list of known hosts= . + signal_handler + echo 'in signal_handler' in signal_handler > Just FYI - I experimented a bit, and was able to do some conditional > waiting on the target with: >=A0 ftc wait-for -t 60 "/bin/bash -c \"source $LOGDIR/prolog.sh ; ov_trans= port_cmd test -f /tmp/sync_file\"" > This could be improved syntactically, but it did work.=A0 I envision exte= nded 'ftc wait-for' to support > something like: >=A0=A0=A0 ftc wait-for "target: test -f /tmp/sync_file" > for this style of board-side conditional test. As fuego is writing the test for running in the host, the host is issuing s= hell comands to the DUT (kind of master-slave), so the HOST to DUT synchron= ization is already implicit. There already is a clear "happens before" rela= tionship in place. It's the other way around, the HOST syncing to the DUT that I couldn't fix.= I was attempting something similar to this (untested): FUEGO_SYNC_PREFIX=3D/tmp/fuego-sync/ # Just clear all the sync files from previous runs function on_test_start() { cmd rm -rf $FUEGO_SYNC_PREFIX && mkdir $FUEGO_SYNC_PREFIX #error handling } function wait_for_dut() { local FILE=3D$FUEGO_SYNC_PREFIX$1 local SEC=3D999999 if [[ ! -z $2 ]]; then=20 SEC=3D$2=20 fi local ELAPSED=3D0 while [[ -n cmd "test -f $FILE" ]]; do if [[ $ELAPSED -lt $SEC ]]; then=20 return 1 fi sleep 1 ELAPSED=3D$((ELAPSED + 1)) done cmd "rm $FILE" return 0 } > This is probably something that would be good to add to the board file. I hand't thought that the board files are just sourced and that I can add v= ariables there. That's powerful. In our case we have more than one serial p= ort on each device though. > That looks great.=A0 I don't know the failure modes for the serial port t= ransfers > so I can't say how robust this is, but it looks OK to me.=A0 As long as s= tty observes > the timeouts, then things shouldn't get stuck. > > I have a minor preference for using TAP format for the test output for th= ese types > of simple test=A0 - basically formatting the output line as: > ok test description > But that's not required, and I think this looks like a nice test. > > I'm trying to think how I can try this here.=A0 I have my test board here= with the > serial port connected to the serial console, but maybe I could wire up a = second > one for testing. Don't bother, I should had posted this as an RFC, I just found easier to sh= are it as a patch than by copying snippets. As the test is done now it isn'= t guaranteed to work correctly, for doing this test properly the sender (HO= ST) would need to start sending (echo) after making sure that the DUT is li= stening (after the launched "dut_rx.sh" script is past the "cat" command = =3D> cat launched as a subprocess). The test is failing for me today. =