[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8bd0f97a0906231511nbac1a3cw1505a51fc2dd837d@mail.gmail.com>
Date: Tue, 23 Jun 2009 18:11:42 -0400
From: Mike Frysinger <vapier.adi@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: linux-kernel@...r.kernel.org,
uclinux-dist-devel@...ckfin.uclinux.org,
Michal Simek <monstr@...str.eu>,
Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH 05/17] Blackfin: convert to generic checksum code
On Tue, Jun 23, 2009 at 18:06, Arnd Bergmann wrote:
> On Tuesday 23 June 2009, Mike Frysinger wrote:
>> and this is an internal tester ... if we're going to let arches
>> override it, then its function signature are pretty much set in stone.
>> i agree we should test every checksum function, but i think only
>> testing do_csum indirectly would be detrimental to the people who
>> would want to use this -- arch maintainers looking to implement
>> do_csum() themselves. otherwise they need to step through the
>> surrounding functions a bit to find the exact values given to
>> do_csum() and the exact value expected back such that the calling
>> function still works. and every arch guy is going to do this same
>> thing.
>
> It depends on how we want to use it. If it's only for testing architecture
> that have moved to the generic checksum code, that's fine. I was
> thinking we could also use it for architectures that want to keep
> their own code, but we don't have to.
ah, i see what you're going for. how about we make testing of
do_csum() dependent upon GENERIC_CSUM. that way we can satisfy
everyone.
any other suggestions for coming up with test vectors ? or i just
extract a few more examples from flooding my board and call it a day.
if someone complains a bug existed and current test vectors didnt
cover it, then they should submit a new one.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists