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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 26 May 2008 02:57:43 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Tom Spink <tspink@...il.com>,
	Vegard Nossum <vegard.nossum@...il.com>,
	Sam Ravnborg <sam@...nborg.org>,
	Steve French <smfrench@...il.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: kernel coding style for if ... else which cross #ifdef

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/