Re: [PATCH] lib/atomic64_test: do not build on non-atomic64 systems

[Mike Frysinger]

On Fri, Oct 22, 2010 at 17:00, Andrew Morton wrote:
> On Fri, 22 Oct 2010 16:47:36 -0400 Mike Frysinger wrote:
>> On Fri, Oct 22, 2010 at 16:31, Andrew Morton wrote:
>> > On Fri, 22 Oct 2010 16:14:49 -0400 Mike Frysinger wrote:
>> >> On Thu, Oct 21, 2010 at 19:24, Andrew Morton wrote:
>> >> > On Thu, 21 Oct 2010 19:04:36 -0400 Mike Frysinger wrote:
>> >> >> you can say "lazy" all you like. __i dont see the point in going that route.
>> >> >
>> >> > Try
>> >> >
>> >> > __ __ __ __grep HAVE arch/x86/Kconfig
>> >> >
>> >> > If all of those were instead to use some random #define which the
>> >> > particular feature happened to define in some header file then we would
>> >> > have a mess on our hands.
>> >>
>> >> fun times. __new tact.
>> >>
>> >> Luca: your new atomic64_t test build fails on all arches that lack
>> >> atomic64_t. __please fix.
>> >
>> > That's only part of the problem. __The following won't build also:
>> >
>> > net/rds
>>
>> not true. Âthat code base is already using my suggestion:
>> net/rds/rds.h:
>> #ifdef ATOMIC64_INIT
>> #define KERNEL_HAS_ATOMIC64
>> #endif
>
> IOW, your suggestion led to a nasty local hack. ÂOne which would be
> unneeded had we implemented this properly via Kconfig.

no.  mine was specific to the atomic64 api and not random consumers.
the test code is tightly coupled to the atomic64 api by nature, so my
proposal as constrained by the single instance makes perfect sense.
as soon as you start talking about more things needing to know "is
atomic64 available" and doing so at the config dependency level, then
a Kconfig option makes sense.  thus i didnt and still dont buy your
original argument against the original patch and constraint.  but with
real tree data, your suggestion makes sense.  perhaps i'll implement
it if i find time.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/