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@xxxxxxxxx> > > > > > > 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx