[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080524134815.116feb9d.akpm@linux-foundation.org>
Date: Sat, 24 May 2008 13:48:15 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Sam Ravnborg <sam@...nborg.org>
Cc: linux-kbuild <linux-kbuild@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Roman Zippel <zippel@...ux-m68k.org>,
Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: [RFC PATCH] kconfig: introduce KCONFIG_* symbols for .c files
On Sat, 24 May 2008 22:24:27 +0200 Sam Ravnborg <sam@...nborg.org> wrote:
> > It could help to get us out of the occasional sticky situation, but it
> > does seem a bit risky. What happens with Kconfig variables which are
> > just not known about at all with some .configs?
> >
> > Silly example, one could add
> >
> > if (KCONFIG_DVB_VES1820)
> >
> > to kernel/sched.c and that would work happily until someone sets DVB=n,
> > in which case I assume KCONFIG_DVB_VES1820 doesn't get defined
> > anywhere?
> It would have helped if I had applied the correct patch...
> All boolean and tristate symbols in the konfiguration have
> their symbols defined as KCONFIG_* no matter their values.
> So KCONFIG_DVB_VES1820 would get defined.
But there are still holes - KCONFIG_ARCH_FOOTBRIDGE wouldn't be defined
on x86, for example. Anything which is inside an `if' or inside an
if/source/endif will not be known about? I assume?
It's all probably not a big problem in practice - we'd need to be
more-than-usually-silly to trip over things like this.
--
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