linux-kernel - Re: [PATCH] scripts/checksyscalls.sh: only whine perf_counter

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] [day] [month] [year] [list]

Message-ID: <8bd0f97a0906140447v3da94323k413f4319cc06fe53@mail.gmail.com>
Date:	Sun, 14 Jun 2009 07:47:10 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Paul Mundt <lethal@...ux-sh.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scripts/checksyscalls.sh: only whine perf_counter_open 
	when supported

On Sun, Jun 14, 2009 at 07:20, Paul Mundt wrote:
> On Sun, Jun 14, 2009 at 06:55:45AM -0400, Mike Frysinger wrote:
>> if we can agree on centralizing arch/Kconfig for HAVE_xxx stubs, we
>> could add a checkpatch that errors out if said stub lacks a help line
>> -- the assumption being the help text would point to arch details and
>> not some other document (design rational, user interface, methodology,
>> etc...).  of course, this also relies on the assumption of people
>> filtering via checkpatch.pl ...
>
> arch/Kconfig exists for architecture-specific HAVE_xxx stubs, and ought
> to have some mention of where to look for wiring up said stub. Individual
> features that may or may not be supported by the entire architecture are
> best off defined within the Kconfig they are used in.

off the top of my head, i cant think of any HAVE_xxx stub that doesnt
require some level of arch support.  and since these are things arch
people should be looking at, having them all in arch/Kconfig makes
sense.  although atm, that file seems to also have oprofile options
... but considering what a mess oprofile is in terms of integration
with any piece of the build system, perhaps we should ignore it and
heed it as a warning of how to not do things.

scanning the myriad of options out there shows some variety that
should probably be condensed.  for example, we have:
 - HAVE_xxx - the arch has support for xxx
 - GENERIC_xxx - dual meaning here -- generic support for xxx exists
if you want it, but sometimes it requires the arch to have support for
some piece of xxx first
 - xxx_SUPPORT - the arch has support for xxx
 - ARCH_WANT_xxx - feature xxx exists, iff the arch has support for it
and wants it

i cant think of any place where xxx_SUPPORT shouldnt actually be HAVE_xxx

> Having to hunt down new HAVE_xxx stubs is almost as tedious as having to
> hunt down the required support interface that goes along with them. In
> practice I generally just select HAVE_foo and see where the build blows
> up to figure out what I have to do first. But this of course assumes you
> have some visibility of new HAVE_xxx stubs.

you can search for it with some kconfig interfaces, but in general it
does suck currently.
-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/