Kernel headers trouble
rob at landley.net
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