CONFIG_* defines

[Rob Landley]

On Tuesday 06 September 2005 14:10, Bernhard Fischer wrote:
> >Why BUSYBOX_APPLET_NAME?
>
> Because it minimizes the risk to clash with the default (kernel's et al)
> CONFIG_ hierarchy now and at any point int the future.

A risk that only exists because we grabbed the kernel's config system in the 
first place, I might add.

In theory, these symbols should not be exposed to userspace.  Maszur's cleaned 
up kernel headers certainly don't include this.  (Of the many broken things 
about glibc's headers, this probably doesn't even register, of course.  Ever 
looked at the fix_includes script?  Makes your brain hurt...)

By the way, the reason they have a common prefix for configuration symbols is 
it's easy to grep the project for, which is a very good thing.  

> >I think, best is
> >CONFIG_APPLETNAME, APPLET_FEATURE_NAME, BB_FEATURE_NAME.
>
> I beg to differ.
> CONFIG_APPLETNAME is inherently broken.

I disagree.  Using maszur's headers there's no clash.  Glibc's headers that 
pollute the standard namespace with kernel implementation details are what's 
broken.

> Iff we can agree (not that i'm 
> in the position to say anything ;) on BUSYBOX_APPLETNAME and
> BB_FEATURE_NAME, then ok. Everything else it is error prone, in
> practice.

I mentioned switching stuff over to 0/1 based symbols (rather than 
undefined/devined) with the prefix ENABLE_ instead of CONFIG_.  The reason 
for this was to avoid a big flag day patch changing all the existing config 
symbols all at once, but if you want I can indeed change them all at once.

Every existing #ifdef CONFIG_* would become #if ENABLE_*, and #ifndef would 
become #if !ENABLE_*...

> PS: there are also other bb*() namespaces, to name just one, libbb from
> blackbox-tools. I'm not arguing that libbb there is better named than
> the local libbb, but i still think that it should be possible to avoid
> potential namespace clashes and perusing a meaningful namespace for a
> given project.

If you check in a patch with that level of paranoia, I'm likely to submit a 
patch prefixing a "unique" symbol to every single function, global variable, 
macro, and so on.

Look, do we link with code from blackbox-tools?  Do we expect to link with it?  
Years ago I had the introduction of C++ support in my compiler break code of 
mine that legitimately had a function called "throw" (which had nothing to do 
with exceptions).  There's no way I could have predicted that.

You deal with problems as they arise, because otherise you start hallucinating 
the need for extensive infrastructure to deal with problems that never arise.  
(The really amusing variants of these are problems people sort of predicted, 
that turned out to be different enough in practice that they would have been 
easy to deal with except for this horrible infrastructure that was put in 
place that only ends up making things worse.  Been there, had to deal with 
the fallout...)

> That said, libbusybox.so which includes all the 
> helper-libs mentione in an other thread before still would _currently_
> pollute the global symbol space via it's far too generic bb_*()
> functions (it wouldn't in practice, but it's error prone) but it would
> at least help the linker to be able to choose the correct lib to use.

What on _earth_ are you talking about?  People only link to the libraries they 
need.  You can legitimately call a symbol "fred" in a library, it just means 
that _if_ you link in two libraries that both define "fred", you get the one 
from whichever library you linked in first.

I've done this.  It's not a real problem.  Honestly.  (I've even seen projects 
deal with this by creating a small library that links to another library to 
wrap and re-export certain symbols under another name.  Admittedly it's been 
a long time since I've seen this because despite doom and gloom predictions 
to the contrary, it hardly ever actually happens in practice...)

Rob