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]
Date:	Mon, 18 Sep 2006 10:43:27 +0200
From:	Jes Sorensen <jes@....com>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>, karim@...rsys.com,
	Andrew Morton <akpm@...l.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Tom Zanussi <zanussi@...ibm.com>, ltt-dev@...fik.org,
	Michel Dagenais <michel.dagenais@...ymtl.ca>
Subject: Re: [PATCH 0/11] LTTng-core (basic tracing infrastructure) 0.5.108

Roman Zippel wrote:
> Hi,
> 
> On Mon, 18 Sep 2006, Nick Piggin wrote:
> 
>> But equally nobody can demand that a feature go into the upstream
>> kernel. Especially not if there is a more flexible alternative
>> already available that just requires implementing for their arch.
> 
> I completely agree with you under the condition that these alternatives 
> were mutually exclusive or conflicting with each other.

Roman,

I don't get this, you are arguing that we should put it in because it
doesn't do any damage. First of all it does, by adding a lot of clutter
all over the place. Second, if we take that argument, then we should
allow anybody to put in anything they want, are you also suggesting we
put devfs back in?

Point is that the Linux kernel gets so many proposals, some are good
some are bad and some while maybe looking like a good idea at the
beginning, show out later to be a bad idea - LTT falls into this
category. *However*, it doesn't mean the knowledge and tools that were
developed with LTT are bad or useless.

To take another related project, look at relayfs. There was so much
noise about it when it was initially pushed, yuck I even remember how it
was suggested that printk should be implemented via relayfs. But look at
it now, there is no fs/relayfs/* these days. The kernel moved on, used
the knowledge optained and provided the feature in a better way -
exactly like it is being proposed to do for trace points, by using
dynamic probes.

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