Kernel headers trouble

[Rob Landley]

On Tuesday 06 December 2005 14:08, Bernhard Fischer wrote:
> On Tue, Dec 06, 2005 at 01:05:07PM -0600, Rob Landley wrote:
> >On Tuesday 06 December 2005 10:13, Mike Frysinger wrote:
> >> On Tue, Dec 06, 2005 at 03:49:11PM +0100, Tito wrote:
> >> > I put thogether a simple script (attached) to check clashes in kernel
> >> > headers.
> >>
> >> so why havent we just done a global sed 's:CONFIG_:BB_CONFIG_:g' yet ?
> >> -mike
> >
> >1) In my case, I'm trying to migrate the CONFIG_ symbols to ENABLE_
> > symbols. I wouldn't be against some other prefix if it was shorter to
> > type.  (BB_ works for me.  We've already got _FEATURE_ on most of the
> > ones that aren't applets.)
>
> Rob, we are talking about *{,/*/}Config.in where we need BB_CONFIG as
> opposed to the CONFIG_ we have now.

_We_ aren't broken.  Their kernel headers are.  (Admittedly it's a common 
mistake we could avoid.  But the bug isn't ours.)

> mkdep then will generate ENABLE_ out of the BB_CONFIG_ kconfig, see?

mkdep doesn't generate ENABLE.  The makefile generates ENABLE via sed.  CONFIG 
and ENABLE are different _kinds_ of symbols.  ENABLE is always present and 
its value says what it is.  CONFIG's value is irrelevant, its presence is 
what is tested for.

> Nothing is holding us back to just s/CONFIG_/BB_CONFIG_/g right now,
> just touching the three aforementioned applets is the minimum we should
> do in the very near future (tito volunteered to do this earlier today).

Actually, tito volunteered to switch them over to ENABLE, which seems the 
thing to do.

CONFIG_TR, CONFIG_WATCHDOG, and what was the third?

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.