All of lore.kernel.org
 help / color / mirror / Atom feed
* [Fuego] Add NEED_PROGRAM to need_check
@ 2018-01-31  7:58 Liu, Wenlong
  2018-02-01  1:27 ` Tim.Bird
  2018-02-07  3:16 ` Bird, Timothy
  0 siblings, 2 replies; 9+ messages in thread
From: Liu, Wenlong @ 2018-01-31  7:58 UTC (permalink / raw)
  To: fuego


[-- Attachment #1.1: Type: text/plain, Size: 339 bytes --]

Hi Tim, Daniel and other friends

I didn’t add the contents of the attachments in this mail, because I just want to confirm
that if it will be better to move those check steps from pre_check to check_needs.

If I'm not mistaken, we've talked about it on the maillist before, but I can't find that mail now.

Best regards
Liu




[-- Attachment #1.2: Type: text/html, Size: 3687 bytes --]

[-- Attachment #2: 0001-need_check-add-support-for-NEED_PROGRAM-check.patch --]
[-- Type: application/octet-stream, Size: 1903 bytes --]

From 87154b9214d8eaf08e25f9c146a6195defc8463f Mon Sep 17 00:00:00 2001
From: Liu Wenlong <liuwl.fnst@cn.fujitsu.com>
Date: Tue, 30 Jan 2018 16:06:30 +0800
Subject: [PATCH 4/6] need_check: add support for NEED_PROGRAM check

Those necessary commands could be defined in fuego_test.sh,
then, Fuego will check if those commands exist in the path
that specified in $PATH of the target.

If not all necessary commands exist on the target, the current
test will be aborted, but Fuego will list the error info.

Signed-off-by: Liu Wenlong <liuwl.fnst@cn.fujitsu.com>
---
 engine/scripts/need_check.sh | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/engine/scripts/need_check.sh b/engine/scripts/need_check.sh
index 1fd6d6d..bc0fa14 100755
--- a/engine/scripts/need_check.sh
+++ b/engine/scripts/need_check.sh
@@ -291,6 +291,26 @@ function check_root {
   fi
 }
 
+# check if those specified commands exist on board
+# $1 has single string with a list of command entries to check for
+function check_program {
+  # split $1 on whitespace, without file globbing
+  set -f
+  arg_array=($1)
+  set +f
+
+  for prg in "${arg_array[@]}" ; do
+    is_on_target_path $prg prg_path
+    if [ -z "$prg_path" ] ; then
+      echo -e "\n\nABORTED: Expected command \"$prg\" is on the target, but it's not there!"
+      return 1
+    fi
+  done
+
+  # return OK if all necessary commands exist on the target
+  return 0
+}
+
 function check_needs {
   # check for each possible need variable and process it
   if [ -n "${NEED_MEMORY}" ] ; then
@@ -325,5 +345,14 @@ function check_needs {
       return $rcode
     fi
   fi
+
+  if [ -n "${NEED_PROGRAM}" ] ; then
+    check_program "${NEED_PROGRAM}"
+    rcode=$?
+    if [ $rcode -ne 0 ] ; then
+      echo "ABORTED: \"${NEED_PROGRAM}\" are required, but not all exist on the target"
+      return $rcode
+    fi
+  fi
 }
 
-- 
2.7.4


[-- Attachment #3: 0002-imagemagick-add-pre_check-for-those-necessary-comman.patch --]
[-- Type: application/octet-stream, Size: 1024 bytes --]

From 4be785e74d42ef288861b5ee5b20c413a102b2bb Mon Sep 17 00:00:00 2001
From: Liu Wenlong <liuwl.fnst@cn.fujitsu.com>
Date: Tue, 30 Jan 2018 16:15:50 +0800
Subject: [PATCH 5/6] imagemagick: add pre_check for those necessary commands

Defined the NEED_PROGRAM variable, and it will be used in
the "Test Dependencies Check" step.

Signed-off-by: Liu Wenlong <liuwl.fnst@cn.fujitsu.com>
---
 engine/tests/Functional.imagemagick/fuego_test.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/engine/tests/Functional.imagemagick/fuego_test.sh b/engine/tests/Functional.imagemagick/fuego_test.sh
index b21eb77..0934afb 100755
--- a/engine/tests/Functional.imagemagick/fuego_test.sh
+++ b/engine/tests/Functional.imagemagick/fuego_test.sh
@@ -1,6 +1,8 @@
 #tarball=jpeg-6b.tar.gz
 tarball=images.tar.gz
 
+NEED_PROGRAM="convert compare mogrify composite identify conjure montage stream"
+
 function test_build {
 #    ./configure --host=$PREFIX --build=`./config.guess` CC="$CC" AR="$AR" RANLIB="$RANLIB"
 #    make
-- 
2.7.4


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [Fuego] Add NEED_PROGRAM to need_check
  2018-01-31  7:58 [Fuego] Add NEED_PROGRAM to need_check Liu, Wenlong
@ 2018-02-01  1:27 ` Tim.Bird
  2018-02-01  2:22   ` Liu, Wenlong
  2018-02-07  3:16 ` Bird, Timothy
  1 sibling, 1 reply; 9+ messages in thread
From: Tim.Bird @ 2018-02-01  1:27 UTC (permalink / raw)
  To: liuwl.fnst, fuego



> -----Original Message-----
> From Liu, Wenlong
> Hi Tim, Daniel and other friends
> 
> 
> 
> I didn't add the contents of the attachments in this mail, because I just want
> to confirm
> 
> that if it will be better to move those check steps from pre_check to
> check_needs.
> 
> If I'm not mistaken, we've talked about it on the maillist before, but I can't
> find that mail now.

In general, I prefer things to be done as check_needs, which means they
are declarative, rather than in test_pre_check, which, strictly speaking,
is imperative.

Having declarative dependencies means you can do a static dependency
checker.

This is a welcome addition.  Do you want me to just use these patches,
or do you want to submit them again more formally?

 -- Tim

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Fuego] Add NEED_PROGRAM to need_check
  2018-02-01  1:27 ` Tim.Bird
@ 2018-02-01  2:22   ` Liu, Wenlong
  2018-02-02  7:30     ` Daniel Sangorrin
  0 siblings, 1 reply; 9+ messages in thread
From: Liu, Wenlong @ 2018-02-01  2:22 UTC (permalink / raw)
  To: Tim.Bird, fuego

> -----Original Message-----
> From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
> Sent: Thursday, February 01, 2018 9:27 AM
> To: Liu, Wenlong/刘 文龙 <liuwl.fnst@cn.fujitsu.com>;
> fuego@lists.linuxfoundation.org
> Subject: RE: Add NEED_PROGRAM to need_check
> 
> > -----Original Message-----
> > From Liu, Wenlong
> > Hi Tim, Daniel and other friends
> >
> > I didn't add the contents of the attachments in this mail, because I
> > just want to confirm
> >
> > that if it will be better to move those check steps from pre_check to
> > check_needs.
> >
> > If I'm not mistaken, we've talked about it on the maillist before, but
> > I can't find that mail now.
> 
> In general, I prefer things to be done as check_needs, which means they
> are declarative, rather than in test_pre_check, which, strictly speaking,
> is imperative.
> 
> Having declarative dependencies means you can do a static dependency
> checker.
> 
> This is a welcome addition.  Do you want me to just use these patches, or
> do you want to submit them again more formally?

OK, those patches can be used(I have tested this).

>  -- Tim
> 




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Fuego] Add NEED_PROGRAM to need_check
  2018-02-01  2:22   ` Liu, Wenlong
@ 2018-02-02  7:30     ` Daniel Sangorrin
  2018-02-02  9:25       ` Liu, Wenlong
  2018-02-07  0:42       ` Tim.Bird
  0 siblings, 2 replies; 9+ messages in thread
From: Daniel Sangorrin @ 2018-02-02  7:30 UTC (permalink / raw)
  To: 'Liu, Wenlong', Tim.Bird, fuego

Hi Tim,

> -----Original Message-----
> From: fuego-bounces@lists.linuxfoundation.org [mailto:fuego-bounces@lists.linuxfoundation.org] On Behalf Of Liu, Wenlong
> > In general, I prefer things to be done as check_needs, which means they
> > are declarative, rather than in test_pre_check, which, strictly speaking,
> > is imperative.
> >
> > Having declarative dependencies means you can do a static dependency
> > checker.

But many times we want a dynamic check as well. For example, we may want to 
skip some tests if we don't have root permissions but still run the other tests.

I was wondering if we could kill 2 birds (no pun intended) with one shot:
- during the pre_check phase a script checks for variables that start with NEED_FOO
- then, the script calls check_FOO() for each need.

NEED_ROOT is currently being checked in a function called check_needs. Instead,
we could define a functiona called "check_ROOT" and have it called automatically
when NEED_ROOT=1 is declared on the script. The advantage of this approach, is
that tests can still call "check_ROOT" dynamically.

What do you think?

Thanks,
Daniel










^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Fuego] Add NEED_PROGRAM to need_check
  2018-02-02  7:30     ` Daniel Sangorrin
@ 2018-02-02  9:25       ` Liu, Wenlong
  2018-02-06  5:43         ` Daniel Sangorrin
  2018-02-07  0:42       ` Tim.Bird
  1 sibling, 1 reply; 9+ messages in thread
From: Liu, Wenlong @ 2018-02-02  9:25 UTC (permalink / raw)
  To: Daniel Sangorrin, Tim.Bird, fuego


> -----Original Message-----
> From: Daniel Sangorrin [mailto:daniel.sangorrin@toshiba.co.jp]
> Sent: Friday, February 02, 2018 3:30 PM
> To: Liu, Wenlong/刘 文龙 <liuwl.fnst@cn.fujitsu.com>; Tim.Bird@sony.com;
> fuego@lists.linuxfoundation.org
> Subject: RE: [Fuego] Add NEED_PROGRAM to need_check
> 
> Hi Tim,
> 
> > -----Original Message-----
> > From: fuego-bounces@lists.linuxfoundation.org
> > [mailto:fuego-bounces@lists.linuxfoundation.org] On Behalf Of Liu,
> > Wenlong
> > > In general, I prefer things to be done as check_needs, which means
> > > they are declarative, rather than in test_pre_check, which, strictly
> > > speaking, is imperative.
> > >
> > > Having declarative dependencies means you can do a static dependency
> > > checker.
> 
> But many times we want a dynamic check as well. For example, we may want
> to skip some tests if we don't have root permissions but still run the other
> tests.
> 
> I was wondering if we could kill 2 birds (no pun intended) with one shot:
> - during the pre_check phase a script checks for variables that start with
> NEED_FOO
> - then, the script calls check_FOO() for each need.
> 
> NEED_ROOT is currently being checked in a function called check_needs.
> Instead, we could define a functiona called "check_ROOT" and have it called
> automatically when NEED_ROOT=1 is declared on the script. The advantage
> of this approach, is that tests can still call "check_ROOT" dynamically.
> 
> What do you think?

Sorry, let me say something here:-).
We really need to check something dynamically. 
Daniel, is my understanding as below the same as you said?
...
NEED_PROGRAM="foo1 foo2 foo3"            -> static check

function test_pre_check {
    if check_ROOT; then
        check_PROGRAM "foo4" || ABORT    -> dynamic check; foo4 depends on the ROOT permission.
    else
       # add "foo4" related test to skip list or fail_ok_list.
    fi
}
...

But, maybe oneday we could also use declarative dependencies to do a dynamic check.
Something like(just a draft below), 
...
NEED_PROGRAM="foo1 foo2 foo3"
NEED_PROGRAM_dynamic="foo4, check_ROOT, test4"
# if not ROOT permission, then skip test4 or add it to fail_ok_list
# if ROOT permission but "foo4" not exist; then ABORT
...
It may be more complex somewhere than the example above. But anyway, check_FOO() will be needed.

Best regards
Liu

> Thanks,
> Daniel
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Fuego] Add NEED_PROGRAM to need_check
  2018-02-02  9:25       ` Liu, Wenlong
@ 2018-02-06  5:43         ` Daniel Sangorrin
  0 siblings, 0 replies; 9+ messages in thread
From: Daniel Sangorrin @ 2018-02-06  5:43 UTC (permalink / raw)
  To: 'Liu, Wenlong', Tim.Bird, fuego

Hi Liu,

> -----Original Message-----
> From: Liu, Wenlong [mailto:liuwl.fnst@cn.fujitsu.com]
> Sent: Friday, February 02, 2018 6:26 PM
> To: Daniel Sangorrin; Tim.Bird@sony.com; fuego@lists.linuxfoundation.org
> Subject: RE: [Fuego] Add NEED_PROGRAM to need_check
> 
> 
> > -----Original Message-----
> > From: Daniel Sangorrin [mailto:daniel.sangorrin@toshiba.co.jp]
> > Sent: Friday, February 02, 2018 3:30 PM
> > To: Liu, Wenlong/刘 文龙 <liuwl.fnst@cn.fujitsu.com>; Tim.Bird@sony.com;
> > fuego@lists.linuxfoundation.org
> > Subject: RE: [Fuego] Add NEED_PROGRAM to need_check
> >
> > Hi Tim,
> >
> > > -----Original Message-----
> > > From: fuego-bounces@lists.linuxfoundation.org
> > > [mailto:fuego-bounces@lists.linuxfoundation.org] On Behalf Of Liu,
> > > Wenlong
> > > > In general, I prefer things to be done as check_needs, which means
> > > > they are declarative, rather than in test_pre_check, which, strictly
> > > > speaking, is imperative.
> > > >
> > > > Having declarative dependencies means you can do a static dependency
> > > > checker.
> >
> > But many times we want a dynamic check as well. For example, we may want
> > to skip some tests if we don't have root permissions but still run the other
> > tests.
> >
> > I was wondering if we could kill 2 birds (no pun intended) with one shot:
> > - during the pre_check phase a script checks for variables that start with
> > NEED_FOO
> > - then, the script calls check_FOO() for each need.
> >
> > NEED_ROOT is currently being checked in a function called check_needs.
> > Instead, we could define a functiona called "check_ROOT" and have it called
> > automatically when NEED_ROOT=1 is declared on the script. The advantage
> > of this approach, is that tests can still call "check_ROOT" dynamically.
> >
> > What do you think?
> 
> Sorry, let me say something here:-).
> We really need to check something dynamically.
> Daniel, is my understanding as below the same as you said?
> ...
> NEED_PROGRAM="foo1 foo2 foo3"            -> static check
> 
> function test_pre_check {
>     if check_ROOT; then
>         check_PROGRAM "foo4" || ABORT    -> dynamic check; foo4 depends on the ROOT permission.
>     else
>        # add "foo4" related test to skip list or fail_ok_list.
>     fi
> }
> ...

Yes, something like that would work for me.
 
> But, maybe oneday we could also use declarative dependencies to do a dynamic check.
> Something like(just a draft below),
> ...
> NEED_PROGRAM="foo1 foo2 foo3"
> NEED_PROGRAM_dynamic="foo4, check_ROOT, test4"
> # if not ROOT permission, then skip test4 or add it to fail_ok_list
> # if ROOT permission but "foo4" not exist; then ABORT
> ...
> It may be more complex somewhere than the example above. But anyway, check_FOO() will be needed.

Mmm I think that it would be hard to create something generic that works for all tests with that approach.

Thanks,
Daniel


> 
> Best regards
> Liu
> 
> > Thanks,
> > Daniel
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Fuego] Add NEED_PROGRAM to need_check
  2018-02-02  7:30     ` Daniel Sangorrin
  2018-02-02  9:25       ` Liu, Wenlong
@ 2018-02-07  0:42       ` Tim.Bird
  2018-02-07  1:57         ` Daniel Sangorrin
  1 sibling, 1 reply; 9+ messages in thread
From: Tim.Bird @ 2018-02-07  0:42 UTC (permalink / raw)
  To: daniel.sangorrin, liuwl.fnst, fuego



> -----Original Message-----
> From: Daniel Sangorrin 
> 
> Hi Tim,
> 
> > -----Original Message-----
> > From: fuego-bounces@lists.linuxfoundation.org [mailto:fuego-
> bounces@lists.linuxfoundation.org] On Behalf Of Liu, Wenlong
> > > In general, I prefer things to be done as check_needs, which means they
> > > are declarative, rather than in test_pre_check, which, strictly speaking,
> > > is imperative.
> > >
> > > Having declarative dependencies means you can do a static dependency
> > > checker.
> 
> But many times we want a dynamic check as well. For example, we may want
> to
> skip some tests if we don't have root permissions but still run the other tests.
> 
> I was wondering if we could kill 2 birds (no pun intended) with one shot:
Personally, I've never cared for that expression. ;-)

> - during the pre_check phase a script checks for variables that start with
> NEED_FOO
> - then, the script calls check_FOO() for each need.
> 
> NEED_ROOT is currently being checked in a function called check_needs.
> Instead,
> we could define a functiona called "check_ROOT" and have it called
> automatically
> when NEED_ROOT=1 is declared on the script. The advantage of this
> approach, is
> that tests can still call "check_ROOT" dynamically.
> 
> What do you think?

I don't mind restructuring the code so that some of these dependencies
could be called both explicitly and implicitly.  However, I think the mixed
case is a bit ugly, and I'd rather we just used:
check_root, and NEED_ROOT.

 -- Tim


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Fuego] Add NEED_PROGRAM to need_check
  2018-02-07  0:42       ` Tim.Bird
@ 2018-02-07  1:57         ` Daniel Sangorrin
  0 siblings, 0 replies; 9+ messages in thread
From: Daniel Sangorrin @ 2018-02-07  1:57 UTC (permalink / raw)
  To: Tim.Bird, liuwl.fnst, fuego



> -----Original Message-----
> From: Tim.Bird@sony.com [mailto:Tim.Bird@sony.com]
> Sent: Wednesday, February 07, 2018 9:42 AM
> To: daniel.sangorrin@toshiba.co.jp; liuwl.fnst@cn.fujitsu.com; fuego@lists.linuxfoundation.org
> Subject: RE: [Fuego] Add NEED_PROGRAM to need_check
> 
> 
> 
> > -----Original Message-----
> > From: Daniel Sangorrin
> >
> > Hi Tim,
> >
> > > -----Original Message-----
> > > From: fuego-bounces@lists.linuxfoundation.org [mailto:fuego-
> > bounces@lists.linuxfoundation.org] On Behalf Of Liu, Wenlong
> > > > In general, I prefer things to be done as check_needs, which means they
> > > > are declarative, rather than in test_pre_check, which, strictly speaking,
> > > > is imperative.
> > > >
> > > > Having declarative dependencies means you can do a static dependency
> > > > checker.
> >
> > But many times we want a dynamic check as well. For example, we may want
> > to
> > skip some tests if we don't have root permissions but still run the other tests.
> >
> > I was wondering if we could kill 2 birds (no pun intended) with one shot:
> Personally, I've never cared for that expression. ;-)
> 
> > - during the pre_check phase a script checks for variables that start with
> > NEED_FOO
> > - then, the script calls check_FOO() for each need.
> >
> > NEED_ROOT is currently being checked in a function called check_needs.
> > Instead,
> > we could define a functiona called "check_ROOT" and have it called
> > automatically
> > when NEED_ROOT=1 is declared on the script. The advantage of this
> > approach, is
> > that tests can still call "check_ROOT" dynamically.
> >
> > What do you think?
> 
> I don't mind restructuring the code so that some of these dependencies
> could be called both explicitly and implicitly.  However, I think the mixed
> case is a bit ugly, and I'd rather we just used:
> check_root, and NEED_ROOT.

OK. Actually, I realized that check_needs is already calling to the corresponding 
check_xxx function so both explicit and implicit calls are currently supported.
I was thinking that check_needs could be rewritten with a more object-oriented approach.
But I should rather focus on fixing more important stuff.

Thanks,
Daniel




^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Fuego] Add NEED_PROGRAM to need_check
  2018-01-31  7:58 [Fuego] Add NEED_PROGRAM to need_check Liu, Wenlong
  2018-02-01  1:27 ` Tim.Bird
@ 2018-02-07  3:16 ` Bird, Timothy
  1 sibling, 0 replies; 9+ messages in thread
From: Bird, Timothy @ 2018-02-07  3:16 UTC (permalink / raw)
  To: Liu, Wenlong, fuego

Applied and pushed.

Thanks,
 -- Tim

> -----Original Message-----
> From: fuego-bounces@lists.linuxfoundation.org [mailto:fuego-
> bounces@lists.linuxfoundation.org] On Behalf Of Liu, Wenlong
> Sent: Tuesday, January 30, 2018 11:58 PM
> To: fuego@lists.linuxfoundation.org
> Subject: [Fuego] Add NEED_PROGRAM to need_check
> 
> Hi Tim, Daniel and other friends
> 
> 
> 
> I didn't add the contents of the attachments in this mail, because I just want
> to confirm
> 
> that if it will be better to move those check steps from pre_check to
> check_needs.
> 
> 
> 
> If I'm not mistaken, we've talked about it on the maillist before, but I can't
> find that mail now.
> 
> 
> 
> Best regards
> 
> Liu
> 
> 


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2018-02-07  3:16 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-31  7:58 [Fuego] Add NEED_PROGRAM to need_check Liu, Wenlong
2018-02-01  1:27 ` Tim.Bird
2018-02-01  2:22   ` Liu, Wenlong
2018-02-02  7:30     ` Daniel Sangorrin
2018-02-02  9:25       ` Liu, Wenlong
2018-02-06  5:43         ` Daniel Sangorrin
2018-02-07  0:42       ` Tim.Bird
2018-02-07  1:57         ` Daniel Sangorrin
2018-02-07  3:16 ` Bird, Timothy

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.