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: <4A31C9D6.7070707@davidnewall.com>
Date:	Fri, 12 Jun 2009 12:51:58 +0930
From:	David Newall <davidn@...idnewall.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Pekka Enberg <penberg@...helsinki.fi>,
	Christoph Hellwig <hch@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Al Viro <viro@...iv.linux.org.uk>, Ingo Molnar <mingo@...e.hu>,
	"David S. Miller" <davem@...emloft.net>,
	Stephane Eranian <eranian@...glemail.com>,
	linux-kernel@...r.kernel.org, Paul Mackerras <paulus@...ba.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] Performance Counters for Linux

Linus Torvalds wrote:
> On Fri, 12 Jun 2009, David Newall wrote:
>> Linus Torvalds wrote:
>>     
>>> To take the oprofile example that decided it for me: the code to actually 
>>> support new processors was all done by basically kernel developers. And it 
>>> didn't hit user land for almost a year, because the user-land tools didn't 
>>> take the patch and propagate it up.
>>>       
>> Bad developer, Spot, you only did half the job. Not sure there's much
>> more one can say.
>>     
>
> Umm. The kernel developer _did_ do the job. The patch to the user land 
> side was available for that whole year.

I don't know this oprofile problem you had, only what you've said, which
is that somebody* did the kernel bit and somebody else did the userspace
bit; and the person doing the userspace bit was unresponsive so good
stuff got ignored for a year. That situation did not occur because the
userspace was out-of-tree, it occurred because you let it. You could
have given the userspace (back) to the kernel developer. That's what
you'd eventually do if a kernel sub-system maintainer became
unresponsive, isn't it?

*the singular is intended to include the plural and the male to include
female.


> Anyway, it's clearly not worth discussing this with you. I've tried. I 
> give up. Happily, I don't _need_ to convince you.

Indeed, no, you don't need to convince me, particularly as I've made it
abundantly clear that I'm entirely happy with your decision. Notice I've
not argued with you, merely pointed out inconsistencies in what you've
said. I realise that can be annoying, and acknowledge your absolute
right to be as consistent or inconsistent as you choose. I wasn't (and
still aren't) trying to be annoying, but to confirm there was no
confusion. If you hadn't seen these inconsistencies before, you surely
do now. That actually should be worth your while. I personally welcome
being corrected; andconsider that a trait of an open mind.
--
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