On Wed, 12 Oct 2016, David Weinehall <david.weineh...@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.nik...@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
> +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
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.
Jani Nikula, Intel Open Source Technology Center
Intel-gfx mailing list