Hi! > >> I've used LTP in the past (quite a bit), and I felt there was some > >> advantage to keeping futextest independent. > > > >What advantages did you have in mind? > > Not CVS was a big one at the time ;-) > > OK, I don't mean to be disparaging here... But since you asked, back in > '09 LTP had some test quality issues and I felt I could maintain futextest > to a higher bar independently. To be honest LTP was one of the messiest codebases I've seen and it was hacked up by mostly clueless people (there were even tests with race conditions that were carefully disabled in a way that was not easy to see). It took me months to get to a state where it compiled fine on major distributions. Today we still have quite a bit of legacy code that needs to be cleaned up, however that gets better every day. And most of the testcases are pretty stable, etc. unfortunatelly LTP has a bad reputation which is lot harder to fix than the code itself. > >> Perhaps things have changed enough since then (~2009 era) that we > >> should reconsider. > > > >I've been working on LTP for a about three years now and we happen to do > >quite a lot in that time. The most visible changes would be more proper > >development practices (git, proper build system, code review, LKML > >coding style, documentation, ...) and also huge number of fixes. Now we > >are trying to catch up in coverage too. > > > >> We can discuss the pros/cons there if you like. > > > >I would love to :). > > Does LTP need to own the code, or can it incorporate existing projects and > a sort of aggregator? That is possible as well but not optimal. This approach would need a wrapper script to convert the test exit values to be LTP compatible. > How much LTP harness type code needs to be used? Not much. For this complexity of tests you would just need to call the tst_resm() interface to report success/failure and, at the end of the test, tst_exit() to return the stored overall test status. And ideally call the standard option parsing code and call the test in standard loop so that the test can take advantage of standard options as number of iterations to run, etc. Have a look at: https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines there is simple test example as well as description of the interfaces. -- Cyril Hrubis chrubis@xxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
