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: <20110803115703.GB5768@somewhere.redhat.com>
Date:	Wed, 3 Aug 2011 13:57:05 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	mingo@...hat.com, hpa@...or.com, eranian@...gle.com,
	linux-kernel@...r.kernel.org, acme@...hat.com,
	robert.richter@....com, tglx@...utronix.de,
	cjashfor@...ux.vnet.ibm.com, mingo@...e.hu,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perf/urgent] perf sched: Fix list of events, dropping
 unsupported ':r' modifier

On Wed, Aug 03, 2011 at 01:42:21PM +0200, Peter Zijlstra wrote:
> On Wed, 2011-08-03 at 13:37 +0200, Frederic Weisbecker wrote:
> > On Wed, Aug 03, 2011 at 12:59:21PM +0200, Peter Zijlstra wrote:
> > > On Fri, 2011-01-14 at 07:25 +0000, tip-bot for Stephane Eranian wrote:
> > > > Looks to me like the :r modifier is not supported anymore, so remove it from
> > > > the list of events. 
> > > 
> > > acme, why is that anyway? -R is a fun way to save some typing, but not
> > > supporting :r anymore takes away the option of not getting
> > > PERF_SAMPLE_RAW output for every event.
> > 
> > Because it was very non obvious for people to select this -R or :r
> > every time they wanted to use trace events for tracing. I think
> > there was complaints about that. Moreover nobody seemed to use
> > trace events for non-tracing (perf report, top, annotate, ...)
> > so we decided to always have RAW records so that it works for
> > every cases...unless we lose events because of that.
> > 
> > We can still bring an option to force disabling of raw records.
> 
> That just doesn't compute, they still have to use -R, so what's the harm
> in also having :r?

Nope -R is the default/forced behaviour already.
But even if it wasn't I don't see much the point of ":r". Who wants
to run two trace events and only record the traces of one?

> Also taking away options just because it confuses people sounds like
> gnome, lets just not go there.

You're right but options should be there only to be able to override
sane default common uses. And not the opposite. And the common use
of trace events is for tracing.

We should rather enable tracing by default and disable it through
an option. Like --no-trace or so.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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