Re: [Intel-gfx] [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.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > 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ä 
> 
> 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

Re: [Intel-gfx] [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  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: [Intel-gfx] [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  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: [Intel-gfx] [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: [Intel-gfx] [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  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 
>> > 
>> > 
>> > 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
>> 
>> I'm against converting to bash/python for no
>> benefit.
>
> +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: [Intel-gfx] [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:
> > I'm against converting to bash/python for no
> > benefit.
> 
> +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: [Intel-gfx] [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 
> > 
> > 
> > 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
> 
> I'm against converting to bash/python for no
> benefit.

+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: [Intel-gfx] [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 
> 
> 
> 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

I'm against converting to bash/python for no
benefit.
-- 
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: [Intel-gfx] [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  wrote:
> On to, 2016-10-06 at 16:36 +0300, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä 
>> 
>> 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ä 
>
> 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 


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: [Intel-gfx] [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.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> 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ä 

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