On 03.03.2007 [17:44:48 +1100], David Gibson wrote: > On Fri, Mar 02, 2007 at 05:14:14PM -0800, Nishanth Aravamudan wrote: > [snip] > > Independent of this patch, I'm starting to feel like we could maybe do a > > better job of abstracting out the arch-specific bits of the library > > Perhaps. We could add a per-arch .o file which could override weak > default versions of functions easily enough. Although, in the library > proper, as I recall, the granularity/slice stuff is basically the only > arch dependency and it's not that bad.
Well, the 32-bit apps running out of address space would be i386/ppc specific, as well as the i386 _syscall rewrites. And if we add ia64 and sparc64 support, maybe others. I'm also looking into a general cleanup/reorg of elflink.c, as it has grown quite a bit lately (and will be larger in 1.2) and probably could be better organized from a logic perspective. > > (including some tests which only really have meaning (or even run!) > > on power, for instance). Would people be opposed to perhaps a little > > bit of a reorg, where we have arch-specific hooks for some things, > > which maybe default defined to no-ops. And then a bit of a reoorg of > > run_tests.sh to have a base set of tests run on all archs, and then > > add to those, the arch-specific tests? > > On the tests I strongly disagree. Some of the tests were designed to > pick up arch specific bugs, but they're all written so that they > should pass (perhaps trivially) on any arch. See below, that's not the case currently. > Most of the tests are pretty quick to run, so I don't see that there's > any case where more tests aren't better, even if some are fairly > unlikely to pick anything up except on a particular arch. Well, icache-hygience 32-bit results in: icache-hygeine (32): ./run_tests.sh: line 34: 3905 Segmentation fault PATH="obj$BITS:$PATH" LD_LIBRARY_PATH="$LD_LIBRARY_PATH:../obj$BITS" $ENV "$@" on x86_64, which is plain ugly to see in an otherwise successful run. And slbpacaflush and icache-hygiene have no utility on coherent icache & dcache machines. Then a handful of tests only have meaning on 32-bit or 64-bit archs. I am ok with pushing some of this stuff into the tests themselves (and I think the 32-bit specific ones do checks), however, I guess. More importantly, adding sparc64 and ia64 support, we want a way to skip the tests which we don't support yet, in run_tests.sh. This grouping provides a nice way to do that. Regardless, I can modify my patch to only conditionalize this last part. That is, only run relink & morecore tests for supported archs for now. Would that be ok by you? > Even if it's genuinely impossible to hit the specific bugs on other > archs, the greater the variety of peculiar things we do in the > testsuite, the better our chances are of picking up some new bug for > which we don't have a specific testcase. Oh, I'm not trying to argue against this. But it seems like if a test is trivially going to succed, why clutter the run-time logs with (arguably false) successes? They succeeded, yes, but only because they did nothing. So just don't run it. This would only apply to arch-specific bugs, of course. We run the basic functional tests regardless. Thanks, Nish -- Nishanth Aravamudan <[EMAIL PROTECTED]> IBM Linux Technology Center ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Libhugetlbfs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
