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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1244738098.27363.36.camel@violet>
Date:	Thu, 11 Jun 2009 18:34:58 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Christoph Hellwig <hch@...radead.org>, 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>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] Performance Counters for Linux

Hi Linus,

> > Err, no.   This adds tons of userspace code into tools/ which
> > should not be in the kernel tree but a proper package.
> 
> I disagree.
> 
> We've had tons of cases where we tried to "separate" the user-land code 
> and the kernel code, in the name of "beauty" of whatever.
> 
> It's almost invariably a disaster.
> 
> Look at oprofile. F*ck me, what a horrid piece of crap. It took literally 
> months for the user mode tools to catch up and get the patches to support 
> new functionality into CVS (or is it SVN?), and after that it took even 
> longer for them to become part of a release and be picked up by 
> distributions. In fact, I'm not sure it is part of a release even now - I 
> had to make a bug report to Fedora to get atom and Nehalem support in my 
> tools: I think they took the unofficial patch.
> 
> Or look at the crazy things we used to do for X. It's going away (slowly), 
> because some of the most incestuous things are actually just being 
> integrated into the kernel, and so there's less of the "two broken pieces" 
> approach, and more of a "one working piece" kind of thing.
> 
> So I'd much rather have kernel tools with the kernel, than have to depend 
> on some external entity that doesn't really care.

so do you expect us to merge stuff like ip, iw, rfkill, crda, the WiMAX
tools, the Bluetooth ones and whatever we have that are all have the
same issues to be merged into the kernel source code as well.

I see no reason this can't be maintained properly outside the kernel
source. You will always have bad sheeps and screw-ups, but just putting
everything into one single location is not a good idea either. Other
subsystems do this well and so could Ingo.

Also please consider the distro point of view. All these distros have
already a hard time to keep up with the kernel patches etc. It is a lot
easier to update a userspace package then having to provide a patches
kernel source.

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/