IMO, it certainly beats having a swamp of #ifdef's all over the place (build system, configuration system, source code, run scripts). However, I am very generally in favor of using version control systems to maintain different product variants, so I'm biased. I just find it much easier to check out a branch (or apply a series of patches, which is really the same thing) than to figure out which #ifdef's are in effect.
It would be interesting to see a detailed proposal, or an example involving real targets. /Klas On Fri, Oct 17, 2008 at 11:25 AM, Subrata Modak <[EMAIL PROTECTED]> wrote: > Hi Shane, > > Thanks for bringing out the ghost out of the coffin. This was an issue i > wanted to discuss long back. Now that you have opened up the discussion, > let me put forth my idea. > > I want the LTP test cases to remain as general as they can be. Let the > ways to run the test cases be modified either during build/install time, > or during run time, or both. This can be achieved by creating > directories say: > > ltp/archs/, > ltp/archs/arm/ > ltp/archs/sh/ > ltp/archs/* > > and then create some patch files like: > > ltp/archs/arm/during-build.patch > ltp/archs/arm/during-run.patch > > 1) If the test cases need to be built with different > parameters/identifiers/variables/ifdefs, for a particular architecture, > then let ltp/Makefile detect that and apply say > ltp/archs/*/during-build.patch before it starts to build. So, we get > binaries built and suited to run for that architecture. > > 2) If the test cases need to be run with different parameters, then let > the ltp/runltp detect that particular architecture and apply > ltp/archs/*/during-run.patch on ltp/runtest/* command files and then run > the tests. > > With these we will be able to retain the generalization of the tests and > also run specific instances of tests depending on the architecture, > memory, FS size requirements. > > What i would require is somebody should send me regular patches to > update the ltp/arch/*/*.patch for their particular architectures. So you > think that this is a feasible IDEA ? > > Regards-- > Subrata > > and then have > On Thu, 2008-10-16 at 14:27 -0400, Shane Volpe wrote: >> All, >> >> There are several tests in ltp that, by default, use too much memory >> and cause small embedded systems to run out of RAM leading to kernel >> oom-killer dumps. I have been able to identify most of these tests on >> my system and tweak by trial and error the input parameters to allow >> the test to still run with out causing a omm-killer dump. >> >> Here are two examples that I have had to address to date: >> >> 1.)Fix float tests by adding -n 15 to limit the number of treads to 15 >> which by default is set to 20. >> >> Modified runtest/math, runtest/ltplite and runtest/stress.part2 as follows: >> Changed: >> float_bessel cd $LTPROOT/testcases/bin; float_bessel -v >> float_exp_log cd $LTPROOT/testcases/bin; float_exp_log -v >> float_iperb cd $LTPROOT/testcases/bin; float_iperb -v >> float_power cd $LTPROOT/testcases/bin; float_power -v >> float_trigo cd $LTPROOT/testcases/bin; float_trigo -v >> >> to: >> float_bessel cd $LTPROOT/testcases/bin; float_bessel -v -n 15 >> float_exp_log cd $LTPROOT/testcases/bin; float_exp_log -v -n 15 >> float_iperb cd $LTPROOT/testcases/bin; float_iperb -v -n 15 >> float_power cd $LTPROOT/testcases/bin; float_power -v -n 15 >> float_trigo cd $LTPROOT/testcases/bin; float_trigo -v -n 15 >> >> 2.) Fixed hackbench tests by reducing number of threads/processes active. >> Modified runtest/sched: >> changed: >> hackbench01 hackbench 150 process 1000 >> hackbench02 hackbench 20 thread 1000 >> to: >> hackbench01 hackbench 5 process 1000 >> hackbench02 hackbench 10 thread 1000 >> >> >> There are a handful of other tests I had to modify, but the point of >> this email is not to detail everything but instead to start a >> discussion on how to track *good* settings for different memory >> configurations (16MB, 32MB, 64MB...). I can think of a couple >> possible solutions: >> 1.) a log somewhere (wiki maybe) of system resources (SDRAM) verses >> test parameter tweaks so others have an idea of reasonable parameters >> for the memory intensive tests. >> 2.) Multiple runtest files based on memory size, I personally don't >> like this option as it makes a lot of extra files to maintain, but it >> still is an option. >> 3.) A more advanced solution would be to have ltp detect the available >> RAM and adjust these test cases automatically. >> >> Sorry if this has already been discussed, I searched LTP but have not >> found any postings that address this. >> Regards, >> Shane >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Ltp-list mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/ltp-list > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Ltp-list mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ltp-list > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
