linux-kernel - Re: Ingo, no more kconfig patches

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]

Message-ID: <20080503212429.GT5838@cs181133002.pp.htv.fi>
Date:	Sun, 4 May 2008 00:24:29 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Ingo, no more kconfig patches

On Sat, May 03, 2008 at 11:03:00PM +0200, Ingo Molnar wrote:
> 
> * Adrian Bunk <bunk@...nel.org> wrote:
>...
> > > As Sam said it, fixing that Kconfig design bug would be "nice" - but 
> > > unfortunately the Kconfig subsystem is not actively developed 
> > > anymore.
> > 
> > Roman is still active.
> 
> great, does this mean we'll see fixes for select's misbehavior, along 
> the lines of Sam's suggestions?

In the case of the problem here it would have turned one problem into 
another, and Roman's patch is the correct solution no matter whether 
you change the semantics of select or not.

> at minimum a warning needs to be emitted by the kconfig tool if such 
> incomplete selects are used. I've stopped counting the number of times 
> such issues have broken the build and have held up kernel development. 

It might held up your randconfig compiles.

Actual kernel development isn't much affected.

Before you started your randconfig builds and sending (often buggy) 
kconfig patches like crazy there wasn't a problem (and Toralf's 
randconfig builds already catched these problems in the past).

> All the information is already in the Kconfig files for the kconfig 
> tool/subsystem to make an intelligent decision. It's just not fully 
> used, and the burden of fixing these problems is pushed back to the 
> developers who create the Kconfig files.

That's nonsense.

Describe the semantics you want for "bool selects tristate", and no 
matter which you choose I'll tell you a case where it breaks.

You've shown with another of your recent kconfig patches that you don't 
even understand how "depends on" works, and you are _very_ far from 
making claims like the one you just made.

Please accept the fact that while I'm (at least at the moment) not 
qualified to make any deeply technical remarks on e.g. the CPU scheduler 
or x86 details, you are (at least at the moment) not qualified to make 
any deeply technical remarks on kconfig.

> 	Ingo

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/