Re: [PATCH i-g-t 0/3] Convert sh scripts to C variants.

Daniel Vetter
2016-10-24T08:46:18Z

On Fri, Oct 21, 2016 at 10:38:17AM +0300, Joonas Lahtinen wrote:
> On pe, 2016-10-21 at 00:00 +0300, Jani Nikula wrote:
> > > On Thu, 20 Oct 2016, Marius Vlad <marius.c.vlad@intel.com> wrote:
> > >
> > > This series adds some library support to help converting sh
> > > scripts to C version. Converted drv_module_reload_basic and
> > > kms_sysfs_edid_timing.
> >
> > >
> > >  18 files changed, 600 insertions(+), 180 deletions(-)
> >
> > Someone please justify this, plus pulling in two new dependencies. I can
> > think of a thing or two, but it needs to be in the commit messages. And
> > I'm not convinced by the justification I came up with.

- Be able to reuse the subtest/logging/whatever else igt stuff for more
consistency, without having to reinvent the wheel in the bash world a
2nd time. Often this is also tricky (we have unit tests for igt
libraries for a reason). I rejected C++ as a new language for similar
reasons, I think getting rid of bash is useful.

- dmesg logging. Imo the piglit dmesg capturing serious sucks, it'd be
great to move it into igt. Reasons for that: a) in C it's much faster,
b) integrated with igt logging (consistent timestamps, ordering,
crashbox log, ...) c) we could put the filtering of dmesg next to the
tests, atm it's some rough filter in piglit's igt.py. c) has been one of
Chris' wishlist things, e.g. make underrun tests hunt for underruns
explicitly.

- It's a nice ramp-up task for igt, that's why I bumped it up a bit. Would
be fairly low-prio otherwise.

> Hmm, not sure how Daniel instructed things. Original idea was to just
> execv the same commands as the scripts do. To get rid of the
> interpreter differences and allow running in a minimal environment.

Yeah, I was thinking of a pretty minimal conversion to C with just lots of
calls to system. Maybe long-term we could extract some shared code, but
meh. Creating good libraries is a lot more work than it generally looks
like, and code reuse for code reuse's sake is in my experience often not
worth the hassle.

> I'm myself fine with using the libraries too, I think the tests can
> then be improved upon, just like Chris has commented on a few of them.

Yeah, not against it, but maybe as step 2.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation