Re: kernel coding style for if ... else which cross #ifdef

[Adrian Bunk <bunk@kernel.org>]

On Sat, May 24, 2008 at 10:15:11PM +0100, Jeremy Fitzhardinge wrote:
> H. Peter Anvin wrote:
>> That's a very defeatist stance, and quite frankly bogus.
>
> But <stamp foot> coding is *hard*.
>
>> Doing it as a flag day event is not really practical, which is why we  
>> need a new set of symbols.  However, at that point we can discourage  
>> continuing use of the CONFIG_ symbols and deprecate them over time.  
>> It's not like we're talking about user-space-visible interfaces here!
>
> Well, I'm thinking more along the lines of:
>
>   1. We introduce this <whatever> mechanism
>   2. Hundreds of people pop out of the woodwork thinking "this looks
>      more fun than tweaking whitespace"
>   3. They produce one-hundred trillion "convert #ifdef to if()" patches
>   4. We have one-hundred trillion^2 followup "fix build with this
>      .config" patches
>
> 3 might be enough to finally drive Andrew out of the kernel business,  
> but 4 definitely would be.
>
> The whole point is to try and get config-invariant build breakages, so  
> that we become less dependent on lots of randconfig testing.
>...

We do not have any serious problems where we actually depend on 
randconfig.

randconfig is nice, but even if it would suddenly become no longer 
available we wouldn't have significantely more build breakages in 
stable kernels (perhaps a few more in the pathological cornercases
only randconfig hits).

If this was really "the whole point" it wasn't not worth it.

Real value would come from getting errors for mistyped kconfig variable 
names.

>    J

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed