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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinTFcFHYv0KH7a=G11sZX8hWww8CvHYZ8xe9-3C@mail.gmail.com>
Date:	Fri, 22 Oct 2010 17:07:52 -0400
From:	Mike Frysinger <vapier@...too.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Luca Barbieri <luca@...a-barbieri.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lib/atomic64_test: do not build on non-atomic64 systems

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/