Kernel headers trouble

Rob Landley rob at
Tue Dec 6 22:54:35 UTC 2005

On Tuesday 06 December 2005 13:10, Mike Frysinger wrote:
> On Tuesday 06 December 2005 14:05, 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 ?
> >
> > 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.)
> so you're planning on replacing all CONFIG_ symbols with ENABLE_ ?

In the C code for 1.2, yeah.  The ENABLE symbols can be used in the 
preprocessor #tests or they can be tested in normal C code with if() and 
optimized out.  The CONFIG symbols are _only_ useful to the preprocessor, 
because when they're undefined C blows chunks.

They'll still be CONFIG in kconfig because that produces different semantics 
(defined or undefined) and it would be a big job to rewrite it rather than 
converting at build time.  (And I'm leaving them alone in the makefiles 
because I don't do makefiles enough to convert to different semantics, and 
polluted header files don't affect make anyway.)

Because of the different semantics, converting them right isn't a simple 
matter of a sed invocation.  (It could be done with sed, but that wouldn't 
let us properly take avantage of the new semantics.)

I'd like the C code to stop including config.h eventually.

> > 2) I'm also calling the CONFIG_ stuff leaking into normal #include space
> > a kernel header bug, since polluting the namespace like that is pretty
> > sucky. Most headers don't do that.  The ones that do are broken.  At the
> > very least, they should put one or more _ on the front of those.
> certainly, but it's not something that will ever change

The switchover to ENABLE to should fix it, but that's a side effect of a 
change with other advantages.

As far as Tito can tell, CONFIG_TR and CONFIG_WATCHDOG are the only two with 
conflicts right now, so they can move over first.

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

More information about the busybox mailing list