On 5/15/14, 12:05, "chrubis@xxxxxxx" <chrubis@xxxxxxx> wrote: >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. Thanks Cyril, I'll follow up with you in a couple weeks most likely. I have some urgent things that will be taking all my time and then some until then. Feel free to poke me though if I lose track of it :-) -- Darren Hart Open Source Technology Center darren.hart@xxxxxxxxx Intel Corporation -- 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
