Hi! > > A few thousand tests to be more precise, and also the content tend to > > change between releases, be it test additions or removal and I do not > > think this level of changes is somehing that makes sense to be tracked > > in such database. > > > > It may be better to have more generic description of LTP subsets, there > > are a few obvious e.g. "SysV IPC" or "Timers", and have the LTP > > testrunner map that to actual testcases. The hard task here is to figure > > out which groups would be useful and keep the set reasonably small. > > > > I can move this forward in LTP reasonably quickly we get small list of > > useful groups from kernel develpers. > > Thanks! The thought was if we wanted to encourage contributors to run > these tests before submitting, does running the whole LTP testsuite > make sense or like you said a targeted set would be much better? The best answer is "it depends". The whole LTP run can take hours on slower hardware and may not even test the code you wanted to test, e.g. if you did changes to compat code you have to build LTP with -m32 to actually excercise the 32bit emulation layer. If you changed kernel core it may make sense to run whole LTP, on the other hand changes isolated to a certain subsystems e.g. SysV IPC, Timers, Cgroups, etc. could be tested fairly quickly with a subset of LTP. So I think that we need some kind of mapping or heuristics so that we can map certain usecases to a subsets of tests. -- Cyril Hrubis chrubis@xxxxxxx
