All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Tim.Bird@sony.com>
To: fuego@lists.linuxfoundation.org
Subject: [Fuego] [PATCH] core: add log_this function
Date: Mon, 21 May 2018 18:39:55 +0000	[thread overview]
Message-ID: <ECADFF3FD767C149AD96A924E7EA6EAF7C14CE50@USCULXMSG01.am.sony.com> (raw)

Hey Fuego-ans,

Here is a patch that I applied to fuego-core last week.  I've been doing
some thinking about some longstanding issues with tests that have a
host-side component to their data gathering. Based on this, and recent
discussions on the list, I implemented a new "log_this" function.
It's like the "report" function, but for a host-side command.

I believe this will be a new, important architectural feature of Fuego.

This is part of a broader effort to expand the scope of Fuego testing, from just
target-side testing, to more system-wide testing.  It's clear that for some types of
hardware testing, additional off-DUT frameworks will need to be accessed,
and in some cases controlled.  This new function "log_this" is the start of
support for logging the access to such non-DUT frameworks
(facilities, devices, harnesses, resources, etc.)

I'm also thinking about what's needed to provide for generalized control
of such things.  This is a tricky subject, due to the incredible fragmentation
there is in board control hardware, secondary resource control, and associated
driving software.
However, I'm considering implementing some kind of generic resource
reservation and management system (over the long run - this is not the highest
priority at the moment).

In any event, here's the patch for this little bit, which is actually pretty simple...
--------------
Some tests need to get information and data from host-side
operations, that needs to be reported and analyzed by Fuego.

The log_this function captures the output of commands executed
on the host, and puts it (ultimately) into the test log for a run.
Any command executed with "log_this" is saved during test execution,
and placed in the final testlog.txt, after any
board-side log data (from report and report_append) commands.

There are several tests (especially Fuego self-tests) that could
use this feature, to avoid an awkward sequence of push-to-target,
and report-cat, to get log data from the host into the testlog.

Signed-off-by: Tim Bird <tim.bird@sony.com>
---
 engine/scripts/functions.sh | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/engine/scripts/functions.sh b/engine/scripts/functions.sh
index 0b293db..8fabd85 100755
--- a/engine/scripts/functions.sh
+++ b/engine/scripts/functions.sh
@@ -226,6 +226,21 @@ function report_append {
   return ${RESULT}
 }
 
+# $1 - local shell command
+function log_this {
+  is_empty $1
+
+  RETCODE=/tmp/$$-${RANDOM}
+  touch $RETCODE
+
+  { $1; echo $? > $RETCODE ; } 2>&1 | tee -a ${LOGDIR}/hostlog.txt
+
+  RESULT=$(cat $RETCODE)
+  rm -f $RETCODE
+  export REPORT_RETURN_VALUE=${RESULT}
+  return ${RESULT}
+}
+
 function dump_syslogs {
 # 1 - tmp dir, 2 - before/after
 
@@ -466,6 +481,10 @@ function fetch_results {
     get $BOARD_TESTDIR/fuego.$TESTDIR/$TESTDIR.log ${LOGDIR}/testlog.txt || \
         echo "INFO: the test did not produce a test log on the target" | tee ${LOGDIR}/testlog.txt
 
+    if [ -f ${LOGDIR}/hostlog.txt ] ; then
+        cat ${LOGDIR}/hostlog.txt >> ${LOGDIR}/testlog.txt
+    fi
+
     # Get syslogs
     dump_syslogs ${fuego_test_tmp} "after"
     get ${fuego_test_tmp}/${NODE_NAME}.${BUILD_ID}.${BUILD_NUMBER}.before ${LOGDIR}/syslog.before.txt
-- 
2.1.4


             reply	other threads:[~2018-05-21 18:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21 18:39 Tim.Bird [this message]
2018-05-22  2:21 ` [Fuego] [PATCH] core: add log_this function Daniel Sangorrin
2018-05-22  2:31   ` Daniel Sangorrin
2018-05-22 23:20   ` Tim.Bird

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ECADFF3FD767C149AD96A924E7EA6EAF7C14CE50@USCULXMSG01.am.sony.com \
    --to=tim.bird@sony.com \
    --cc=fuego@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.