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.
> (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. 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.
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.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------------------------------------------------------------------
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
