[PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[ville.syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

debugfs_wedged and drm_lib.sh are already using bashism so switch over
to using #!/bin/bash instead of #!/bin/sh.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 tests/debugfs_wedged | 2 +-
 tests/drm_lib.sh     | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/debugfs_wedged b/tests/debugfs_wedged
index 903a0a20060a..f15ac4614845 100755
--- a/tests/debugfs_wedged
+++ b/tests/debugfs_wedged
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
 . $SOURCE_DIR/drm_lib.sh
diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
index c32bc68dc6a8..0eeab1c183c9 100755
--- a/tests/drm_lib.sh
+++ b/tests/drm_lib.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
 . $SOURCE_DIR/drm_getopt.sh
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH i-g-t 2/5] tests: Leave basic breadcrumbs in dmesg for shell script based tests

[ville.syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Leave the normal "executing" and "exiting" breadcrumbs into dmesg when
running the test.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 tests/drm_lib.sh | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
index 0eeab1c183c9..456040e1971f 100755
--- a/tests/drm_lib.sh
+++ b/tests/drm_lib.sh
@@ -3,6 +3,30 @@
 SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
 . $SOURCE_DIR/drm_getopt.sh
 
+NAME=$(basename "$0")
+
+KERN_EMER="<0>"
+KERN_ALERT="<1>"
+KERN_CRIT="<2>"
+KERN_ERR="<3>"
+KERN_WARNING="<4>"
+KERN_NOTICE="<5>"
+KERN_INFO="<6>"
+KERN_DEBUG="<7>"
+
+kmsg() {
+	echo "$1" > /dev/kmsg
+}
+
+finish() {
+	exitcode=$?
+	kmsg "$KERN_INFO$NAME: exiting, ret=$exitcode"
+	exit $exitcode
+}
+trap finish EXIT
+
+kmsg "$KERN_INFO$NAME: executing"
+
 skip() {
 	echo "$@"
 	exit $IGT_EXIT_SKIP
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 2/5] tests: Leave basic breadcrumbs in dmesg for shell script based tests

[Jani Nikula]

On Thu, 06 Oct 2016, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Leave the normal "executing" and "exiting" breadcrumbs into dmesg when
> running the test.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  tests/drm_lib.sh | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
>
> diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
> index 0eeab1c183c9..456040e1971f 100755
> --- a/tests/drm_lib.sh
> +++ b/tests/drm_lib.sh
> @@ -3,6 +3,30 @@
>  SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
>  . $SOURCE_DIR/drm_getopt.sh
>  
> +NAME=$(basename "$0")
> +
> +KERN_EMER="<0>"
> +KERN_ALERT="<1>"
> +KERN_CRIT="<2>"
> +KERN_ERR="<3>"
> +KERN_WARNING="<4>"
> +KERN_NOTICE="<5>"
> +KERN_INFO="<6>"
> +KERN_DEBUG="<7>"
> +
> +kmsg() {
> +	echo "$1" > /dev/kmsg

If you make that echo "$@", it'll all end up in kmsg even if someone
accidentally uses more than one parameter. But no big deal.

BR,
Jani.

> +}
> +
> +finish() {
> +	exitcode=$?
> +	kmsg "$KERN_INFO$NAME: exiting, ret=$exitcode"
> +	exit $exitcode
> +}
> +trap finish EXIT
> +
> +kmsg "$KERN_INFO$NAME: executing"
> +
>  skip() {
>  	echo "$@"
>  	exit $IGT_EXIT_SKIP

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 2/5] tests: Leave basic breadcrumbs in dmesg for shell script based tests

[Ville Syrjälä]

On Fri, Oct 07, 2016 at 10:24:39AM +0300, Jani Nikula wrote:
> On Thu, 06 Oct 2016, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Leave the normal "executing" and "exiting" breadcrumbs into dmesg when
> > running the test.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  tests/drm_lib.sh | 24 ++++++++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
> > index 0eeab1c183c9..456040e1971f 100755
> > --- a/tests/drm_lib.sh
> > +++ b/tests/drm_lib.sh
> > @@ -3,6 +3,30 @@
> >  SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
> >  . $SOURCE_DIR/drm_getopt.sh
> >  
> > +NAME=$(basename "$0")
> > +
> > +KERN_EMER="<0>"
> > +KERN_ALERT="<1>"
> > +KERN_CRIT="<2>"
> > +KERN_ERR="<3>"
> > +KERN_WARNING="<4>"
> > +KERN_NOTICE="<5>"
> > +KERN_INFO="<6>"
> > +KERN_DEBUG="<7>"
> > +
> > +kmsg() {
> > +	echo "$1" > /dev/kmsg
> 
> If you make that echo "$@", it'll all end up in kmsg even if someone
> accidentally uses more than one parameter. But no big deal.

Changed it, and pushed the lot.

> 
> BR,
> Jani.
> 
> > +}
> > +
> > +finish() {
> > +	exitcode=$?
> > +	kmsg "$KERN_INFO$NAME: exiting, ret=$exitcode"
> > +	exit $exitcode
> > +}
> > +trap finish EXIT
> > +
> > +kmsg "$KERN_INFO$NAME: executing"
> > +
> >  skip() {
> >  	echo "$@"
> >  	exit $IGT_EXIT_SKIP
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH i-g-t 3/5] tests/vgem_reload_basic: Leave breadcrumbs in dmesg

[ville.syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Source drm_lib.sh instead of drm_getopt.sh so that we get the
"executing", and "exiting" breadcrumbs in dmesg.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 tests/vgem_reload_basic | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/vgem_reload_basic b/tests/vgem_reload_basic
index e47af2f54951..46088fc34ee6 100755
--- a/tests/vgem_reload_basic
+++ b/tests/vgem_reload_basic
@@ -6,7 +6,7 @@
 #
 
 SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
-. $SOURCE_DIR/drm_getopt.sh
+. $SOURCE_DIR/drm_lib.sh
 
 function unload() {
 	/sbin/rmmod vgem
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH i-g-t 4/5] tests/tools_test: Fix it up for intel_reg

[ville.syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

intel_reg_read and intel_reg_dumper are no more. Switch over to intel_reg.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 tests/tools_test | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/tools_test b/tests/tools_test
index 04878274e135..a27fb873b029 100755
--- a/tests/tools_test
+++ b/tests/tools_test
@@ -7,8 +7,8 @@ SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
 
 # ARB_MODE has existed for many gens
 PATH=$SOURCE_DIR/../tools:$PATH
-do_or_die "intel_reg_read 0x4030"
-do_or_die "intel_reg_dumper"
+do_or_die "intel_reg read 0x4030"
+do_or_die "intel_reg dump"
 
 # TODO: Add more tests
 
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH i-g-t 5/5] tools/intel_reg: Return SUCCESS after a succesful dump

[ville.syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

No reason why 'intel_reg dump' can't declare success after a succesful
dumping. Spotted after fixing tools_test to use the right tool :)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 tools/intel_reg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/intel_reg.c b/tools/intel_reg.c
index 98dea0faa0e0..01a3671e97dd 100644
--- a/tools/intel_reg.c
+++ b/tools/intel_reg.c
@@ -491,7 +491,7 @@ static int intel_reg_dump(struct config *config, int argc, char *argv[])
 
 	intel_register_access_fini();
 
-	return EXIT_FAILURE;
+	return EXIT_SUCCESS;
 }
 
 static int intel_reg_snapshot(struct config *config, int argc, char *argv[])
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[Joonas Lahtinen]

On to, 2016-10-06 at 16:36 +0300, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> debugfs_wedged and drm_lib.sh are already using bashism so switch
> over
> to using #!/bin/bash instead of #!/bin/sh.
> 
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Just reminds me of my RFC to convert them all to #!/bin/sh. The final
resolution was that all the scripts will be converted into C programs
shortly, there was even a JIRA created for it, Daniel?

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[Jani Nikula]

On Fri, 07 Oct 2016, Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> On to, 2016-10-06 at 16:36 +0300, ville.syrjala@linux.intel.com wrote:
>> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> 
>> debugfs_wedged and drm_lib.sh are already using bashism so switch
>> over
>> to using #!/bin/bash instead of #!/bin/sh.
>> 
>> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Just reminds me of my RFC to convert them all to #!/bin/sh. The final
> resolution was that all the scripts will be converted into C programs
> shortly, there was even a JIRA created for it, Daniel?

The "change" to use bash just reflects current reality. All the changes
here look simple and sane, and immediately improve the results. The work
is already done, no use blocking them because someone might eventually
rewrite them in C. (And it will be a PITA to write the module reload
test in C, so I wouldn't hold my breath.)

For the series,

Reviewed-by: Jani Nikula <jani.nikula@intel.com>


PS. When I look at IGT and the macro/setjmp/longjmp magic to create the
test/subtest/fixture infrastructure, making the tests look like they've
been written in some extended version of C, I have to question whether C
really is the right language for the tests. libdrm python bindings and
python, anyone?


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[Joonas Lahtinen]

On pe, 2016-10-07 at 10:38 +0300, Jani Nikula wrote:
> The "change" to use bash just reflects current reality. All the changes
> here look simple and sane, and immediately improve the results. The work
> is already done, no use blocking them because someone might eventually
> rewrite them in C. (And it will be a PITA to write the module reload
> test in C, so I wouldn't hold my breath.)
> 

The scripts are really simple, most of the scripts even use POSIX sh
compliant constructs but just the wrong shebang. And sometimes some a
advanced bash feature here and there which could be replaced easily.

> For the series,
> 
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> 
> 
> PS. When I look at IGT and the macro/setjmp/longjmp magic to create the
> test/subtest/fixture infrastructure, making the tests look like they've
> been written in some extended version of C, I have to question whether C
> really is the right language for the tests. libdrm python bindings and
> python, anyone?

My patches to convert away from bash were to allow running the tests in
minimal initramfs environment where the kernel + IGT would be a
standalone bzImage suitable for netbooting, but we can go to another
direction too, and lets add Java as runtime requirement for I-G-T!

Regards, Joonas

<plaintext>I'm against converting to bash/python for no
benefit.</plaintext>
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[David Weinehall]

On Fri, Oct 07, 2016 at 12:54:03PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-10-07 at 10:38 +0300, Jani Nikula wrote:
> > The "change" to use bash just reflects current reality. All the changes
> > here look simple and sane, and immediately improve the results. The work
> > is already done, no use blocking them because someone might eventually
> > rewrite them in C. (And it will be a PITA to write the module reload
> > test in C, so I wouldn't hold my breath.)
> > 
> 
> The scripts are really simple, most of the scripts even use POSIX sh
> compliant constructs but just the wrong shebang. And sometimes some a
> advanced bash feature here and there which could be replaced easily.
> 
> > For the series,
> > 
> > Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> > 
> > 
> > PS. When I look at IGT and the macro/setjmp/longjmp magic to create the
> > test/subtest/fixture infrastructure, making the tests look like they've
> > been written in some extended version of C, I have to question whether C
> > really is the right language for the tests. libdrm python bindings and
> > python, anyone?
> 
> My patches to convert away from bash were to allow running the tests in
> minimal initramfs environment where the kernel + IGT would be a
> standalone bzImage suitable for netbooting, but we can go to another
> direction too, and lets add Java as runtime requirement for I-G-T!
> 
> Regards, Joonas
> 
> <plaintext>I'm against converting to bash/python for no
> benefit.</plaintext>

+1, Insightful.

Most of the bashisms seem to be simple cases of the superfluous
"function" in front of functions...


Kind regards, David
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[Joonas Lahtinen]

On ke, 2016-10-12 at 13:12 +0300, David Weinehall wrote:
> On Fri, Oct 07, 2016 at 12:54:03PM +0300, Joonas Lahtinen wrote:
> > <plaintext>I'm against converting to bash/python for no
> > benefit.</plaintext>
> 
> +1, Insightful.
> 
> Most of the bashisms seem to be simple cases of the superfluous
> "function" in front of functions...
> 

Indeed. I'm still all in for converting all scripts under tests
directory to POSIX. Last time it was Nack due to intent to convert over
to C, but if we reflect to reality, we could now do the next best
option and convert to POSIX?

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[Jani Nikula]

On Wed, 12 Oct 2016, David Weinehall <david.weinehall@linux.intel.com> wrote:
> On Fri, Oct 07, 2016 at 12:54:03PM +0300, Joonas Lahtinen wrote:
>> On pe, 2016-10-07 at 10:38 +0300, Jani Nikula wrote:
>> > The "change" to use bash just reflects current reality. All the changes
>> > here look simple and sane, and immediately improve the results. The work
>> > is already done, no use blocking them because someone might eventually
>> > rewrite them in C. (And it will be a PITA to write the module reload
>> > test in C, so I wouldn't hold my breath.)
>> > 
>> 
>> The scripts are really simple, most of the scripts even use POSIX sh
>> compliant constructs but just the wrong shebang. And sometimes some a
>> advanced bash feature here and there which could be replaced easily.
>> 
>> > For the series,
>> > 
>> > Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>> > 
>> > 
>> > PS. When I look at IGT and the macro/setjmp/longjmp magic to create the
>> > test/subtest/fixture infrastructure, making the tests look like they've
>> > been written in some extended version of C, I have to question whether C
>> > really is the right language for the tests. libdrm python bindings and
>> > python, anyone?
>> 
>> My patches to convert away from bash were to allow running the tests in
>> minimal initramfs environment where the kernel + IGT would be a
>> standalone bzImage suitable for netbooting, but we can go to another
>> direction too, and lets add Java as runtime requirement for I-G-T!
>> 
>> Regards, Joonas
>> 
>> <plaintext>I'm against converting to bash/python for no
>> benefit.</plaintext>
>
> +1, Insightful.
>
> Most of the bashisms seem to be simple cases of the superfluous
> "function" in front of functions...

The point here was that the scripts were *already* de-facto bash scripts
and would not have worked on a pure Bourne shell /bin/sh.

For generic scripts I'm fine with striving to keep them free of
bashisms, but at the same time for rather dedicated scripts which
already have a set of specific/non-trivial dependencies, I really can't
be bothered.

If you really care, go ahead and send the patches to make these Bourne
shell compatible, but then do also sign up for testing them on non-bash
shells. The CI won't. I don't think it's worth the trouble, but YMMV.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[Joonas Lahtinen]

On ke, 2016-10-12 at 14:16 +0300, Jani Nikula wrote:
> If you really care, go ahead and send the patches to make these Bourne
> shell compatible, but then do also sign up for testing them on non-bash
> shells. The CI won't. I don't think it's worth the trouble, but YMMV.

If they're re-written using POSIX sh constructs only, I don't think
they need to be tested outside of POSIX sh? That's what standards are
for.

I also remember FreeBSD guys being all for letting bash dependency go.
So there'd be actual gains too.

./scripts/run-tests.sh:            Bourne-Again shell script, UTF-8 Unicode text executable
./scripts/who.sh:                  Bourne-Again shell script, ASCII text executable
./tests/vgem_reload_basic:         Bourne-Again shell script, ASCII text executable
./tests/debugfs_emon_crash:        Bourne-Again shell script, ASCII text executable
./tests/drv_module_reload_basic:   Bourne-Again shell script, ASCII text executable
./tests/ddx_intel_after_fbdev:     Bourne-Again shell script, ASCII text executable
./tests/test_rte_check:            Bourne-Again shell script, ASCII text executable
./tests/tools_test:                Bourne-Again shell script, ASCII text executable
./tests/check_drm_clients:         Bourne-Again shell script, ASCII text executable
./tests/sysfs_l3_parity:           Bourne-Again shell script, ASCII text executable
./tests/drv_debugfs_reader:        Bourne-Again shell script, ASCII text executable
./tests/kms_sysfs_edid_timing:     Bourne-Again shell script, ASCII text executable
./tools/intel_aubdump.in:          Bourne-Again shell script, ASCII text executable

All are easily convertible. So let's do this.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[Jani Nikula]

On Wed, 12 Oct 2016, Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> On ke, 2016-10-12 at 14:16 +0300, Jani Nikula wrote:
>> If you really care, go ahead and send the patches to make these Bourne
>> shell compatible, but then do also sign up for testing them on non-bash
>> shells. The CI won't. I don't think it's worth the trouble, but YMMV.
>
> If they're re-written using POSIX sh constructs only, I don't think
> they need to be tested outside of POSIX sh? That's what standards are
> for.

It's just that if the majority of folks and the CI have bash as /bin/sh,
we won't notice when we accidentally add bashisms, and it'll eventually
break. Maybe you could keep running shellcheck [1] on them, or
something.

[1] https://www.shellcheck.net/

> I also remember FreeBSD guys being all for letting bash dependency go.
> So there'd be actual gains too.

I'm biting my lips not to quip on that.

> All are easily convertible. So let's do this.

If you have the time, go ahead. But don't break *any* functionality, no
compromises.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[David Weinehall]

On Wed, Oct 12, 2016 at 04:04:34PM +0300, Jani Nikula wrote:
> On Wed, 12 Oct 2016, Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> > On ke, 2016-10-12 at 14:16 +0300, Jani Nikula wrote:
> >> If you really care, go ahead and send the patches to make these Bourne
> >> shell compatible, but then do also sign up for testing them on non-bash
> >> shells. The CI won't. I don't think it's worth the trouble, but YMMV.
> >
> > If they're re-written using POSIX sh constructs only, I don't think
> > they need to be tested outside of POSIX sh? That's what standards are
> > for.
> 
> It's just that if the majority of folks and the CI have bash as /bin/sh,
> we won't notice when we accidentally add bashisms, and it'll eventually
> break. Maybe you could keep running shellcheck [1] on them, or
> something.

At the very least most/all Debian and Ubuntu systems use dash as /bin/sh.

It supports a very small subset of the bashisms (most notably local),
and is faster than bash.

> [1] https://www.shellcheck.net/
> 
> > I also remember FreeBSD guys being all for letting bash dependency go.
> > So there'd be actual gains too.
> 
> I'm biting my lips not to quip on that.
> 
> > All are easily convertible. So let's do this.
> 
> If you have the time, go ahead. But don't break *any* functionality, no
> compromises.


Kind regards, David
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

[Daniel Vetter]

On Fri, Oct 07, 2016 at 10:15:19AM +0300, Joonas Lahtinen wrote:
> On to, 2016-10-06 at 16:36 +0300, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > debugfs_wedged and drm_lib.sh are already using bashism so switch
> > over
> > to using #!/bin/bash instead of #!/bin/sh.
> > 
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Just reminds me of my RFC to convert them all to #!/bin/sh. The final
> resolution was that all the scripts will be converted into C programs
> shortly, there was even a JIRA created for it, Daniel?

Still the plan, and I even had "volunteers" for it. Unfortunately they got
ACTed :(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx