linux-kernel - Re: [GIT PULL] Performance Counters for Linux

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Jun 2009 23:17:16 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Martin Bligh <mbligh@...gle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Al Viro <viro@...iv.linux.org.uk>,
	"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

Hi Sam,

> > So you are saying that only good code comes from including it into
> > linux-2.6.git and otherwise you will never get there. Have you actually
> > tried to maintain this in a separate repository on kernel.org?
> 
> Could you please remind us what the arguments agains including a few
> seleted tools within the kernel source tree was.
> 
> I ask because I really cannot see why so much nosie is generated?
> As a naive user that like easy access to the stuff I work with
> this looks like an optimal place to find the kernel-hacking
> tools I need. Why should I hunt somewhere else to find it?

I personally would expect a perf.git on kernel.org for the userspace
tools for it. Like we have udev.git there, iproute2.git and others.

Seems to be working perfectly fine (except of course oprofile) and makes
packaging and security updates a lot easier. The distros have always a
really hard problem with releasing new kernel packages. And as long as
the source changes the whole set of binary packages needs to be rebuilt
and in theory if you install a new kernel, you should reboot. So if
there is an issue in perf userspace, then the current processes in most
distros will propose the user a reboot for no good reason.

There is nothing wrong with trying something new, but to be honest I
don't buy into the arguments why we do it. It seems like it is all based
on bad experience with some userspace maintainers and not really
technical grounds why it is a must to have this inside the kernel source
code. Of course you can make the argument the other way around and say
why not. And I give Linus that he wants to try. However all the
arguments from Ingo are a joke and basically tells that all userspace
developers have no clue and can't get right anyway.

Maybe it is just a sneaky attempt to get a higher hit in Greg's
statistics by just writing some userspace code which otherwise would not
be counted ;)

Regards

Marcel

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