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: <20080503215214.GA18407@elte.hu>
Date:	Sat, 3 May 2008 23:52:14 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Adrian Bunk <bunk@...nel.org>
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

* Adrian Bunk <bunk@...nel.org> wrote:

> > 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.

uhm, you are quite wrong - countless times have people been bitten by 
select's breakages in the past, and not via randconfig. That's the main 
reason why select use in Kconfig was not encouraged for a long time.

Select does make sense in some situations but it's a double-edged sword: 
kconfig does not warn at all about the situations where it's "unsafe" to 
use it - while it has all the information in the Kconfig files to emit 
that warning. Instead we get build breakages not visible when an 
incorrect select is added, but much later, if someone happens to stumble 
on the wrong kind of .config. That is obviously harmful.

My larger point is that this kconfig tool bug breeds a constant stream 
of avoidable breakages, which causes lost manpower and causes a stream 
of trivial patches hindering maintainers all around the tree. Because 
every such trivial patch has to be reviewed, tested, it clogs the commit 
logs, etc.

So the more trivial patches we _avoid_ having to do in the future, the 
better. I'm not sure why you are even arguing against this this rather 
simple point - your arguments are rather hard to understand. Wouldnt you 
be happier if a whole category of trivial breakages was avoided and if 
you didnt have to deal with and waste your time on that category of 
trivial patches anymore?

Most of the time reoccuring trivial patches are an indicator of some 
deeper structural problem - as in this case.

	Ingo
--
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/