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: <20080504003452.GB5838@cs181133002.pp.htv.fi>
Date:	Sun, 4 May 2008 03:34:52 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Ingo Molnar <mingo@...e.hu>,
	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 Sun, May 04, 2008 at 01:22:15AM +0200, Thomas Gleixner wrote:
> On Sun, 4 May 2008, Adrian Bunk 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.
> 
> Interesting. You confidently define how kernel development works and
> what affects it and what not. 
> 
> I just caught a build wreckage via randconfig builds on a patch which
> was sent through Andrew to x86 for merging into mainline.
> 
> So you think that we should stop sharing with the wider kernel
> community the fixes that result out of our automated randconfig builds
> and should instead wait for Joe User or another kernel developer to
> trip into some subtle missing Kconfig dependency, just because a fix
> might not be the right one and might need another iteration before it
> can go upstream?
> 
> You are wrong as usual.
> 
> I for one prefer getting a (even wrong) patch which points to the
> problem instead of some (often grumpy) "this broke" message.

Ingo' message that caused me to change the subject of this thread was
  http://lkml.org/lkml/2008/4/30/446

Ingo's patch did not point at the actual problem at all (it was a x86 
bug and Ingo's patch was for input). But he tried to push his bogus 
patch through Dmitry who had correctly stated that the patch was wrong.

This way of "sharing fixes" even against a correct maintainer NAK is 
what annoys me.

Am I really wrong as usual on that?

And most issues randconfig finds are some cornercases unlikely to happen 
for users (hey, this thread is about a bug only occuring in 
configurations that include support for an X-Box gamepad in a kernel for 
an RDC R-321x SoC), so there's usually no need to hurry but time to look 
at the problem and fix it properly.

> > 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).
> 
> FYI, Ingo has been doing randconfig build and boot tests for a long,
> long time. There are dozens and dozens of (non-build) fixes in the
> upstream kernel that resulted from that effort - it's really valuable
> in practice.

Since when is he actually doing regular randconfig builds?

The only person from whom I'm aware of regularly seeing reports of build 
breakages with randconfig on linux-kernel for many years is Toralf.

> So what you say is complete nonsense.
> 
> The RDC subarch commit was buggy, but that does not justify your
> insulting and self-righteous behaviour at all. If you think that your
> behaviour vs. Ingo is improving kernel development, then you are on
> the completely wrong track. It might earn you an entry in his
> killfile, but nothing else.

When talking about "self-righteous behaviour" please also talk about how 
Ingo rants about kconfig and makes statements like "All the information 
is already in the Kconfig files for the kconfig tool/subsystem to make 
an intelligent decision." [1] that are simply wrong.

> Thanks,
> 
> 	tglx

cu
Adrian

[1] http://lkml.org/lkml/2008/5/3/215

-- 

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ