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@xxxxxxxxx> 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 http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
