linux-kernel - Re: [GIT] HID patches for 2.6.28

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] [day] [month] [year] [list]

Date:	Wed, 15 Oct 2008 13:20:39 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jiri Kosina <jkosina@...e.cz>, Jean Delvare <khali@...ux-fr.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Jiri Slaby <jirislaby@...il.com>,
	Vegard Nossum <vegard.nossum@...il.com>
Subject: Re: [GIT] HID patches for 2.6.28

On Wed, Oct 15, 2008 at 12:02:52PM +0200, Ingo Molnar wrote:
> 
> * Jiri Kosina <jkosina@...e.cz> wrote:
> 
> > On Wed, 15 Oct 2008, Ingo Molnar wrote:
> > 
> > > this or the I2C updates cause widespread build failures in latest -git:
> > 
> > For the usbhid_set_leds(), Adrian has already sent me a fix [1]. 
> > Still, I would like to understand whether this failure is bug or 
> > feature in select/depends handling in Kconfig, because it seems to 
> > behave differently from what I was expecting.
> 
> yes, it's a kconfig bug: Kconfig must either not allow complex selects 
> (during its initial parsing pass of the Kconfig dependnecy tree) or 

Are we removing RCU only because people constantly get it wrong?

If you do RCU stuff without asking Paul for review it might be wrong, 
and if you are doing complex stuff in kconfig without asking Roman or
me the same applies.

> handle the dependencies correctly.

When you claim that there was one "correct" way to handle them
that's FUD, and shows that you don't understand the problem.

> The current "allow them silently and pepper the kernel with build 
> errors" approach is obviously silly.
> 
> We already have over 100 bugfixes in the tree from the past 3 years due 
> to kconfig's inability to figure out the correct dependencies. (count: 
> rising steadily)

Again, there are no "correct dependencies".

Continously repeating the same FUD doesn't make it true.

I have yet to see someone giving a semantics for select that would solve 
as many problems as the FUD claims without introducing new problems.

> Changes to the Kconfig tool to address this design bug did not get 
> picked up. See for example this quick patch from Vegard half a year ago:
> 
>   http://lkml.org/lkml/2008/5/4/13
> 
> that patch was not adopted and the config options in the warning log 

I remember that patch, Vegard himself admitted it was wrong:
  http://lkml.org/lkml/2008/5/4/48

Not sure why you whine about a broken patch not being applied...

> were later on frequent participants in build failures and subsequent 
> stream of trivial fixes.

The assumption that kconfig was trivial or all kconfig fixes were 
trivial is completely wrong.

I might just remind you of http://lkml.org/lkml/2008/4/30/446 where you 
tried to push a broken kconfig patch of yours through the Input 
maintainer (who had correctly rejected it), and the actual bug was
in the x86 code you maintain.

Something isn't trivial only because you don't understand it.

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