Re: [PATCH] scripts/checksyscalls.sh: only whine perf_counter_open when supported

[Mike Frysinger <vapier.adi@gmail.com>]

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