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] [day] [month] [year] [list]
Message-ID: <20140902091744.GC8044@krava.redhat.com>
Date:	Tue, 2 Sep 2014 11:17:44 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	Adrian Hunter <adrian.hunter@...el.com>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, David Ahern <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Namhyung Kim <namhyung@...il.com>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH 20/41] perf tools: Let a user specify a PMU event without
 any config terms

On Tue, Sep 02, 2014 at 08:39:56AM +0300, Adrian Hunter wrote:

SNIP

> >>>   -e intel_pt/tsc=1,noretcomp=0/
> >>>
> >>> I guess I wanted to hear more elaboration why is this better
> >>> than the current way we have by defining an alias, like:
> >>>
> >>>   krava alias: "tsc=1,noretcomp=0"
> >>>
> >>>   -e intel_pt/krava/
> >>>
> >>> which gives the same result
> >>
> >> The default value must be provided by perf tools not the kernel e.g.
> >> an older version of perf tools will not be aware of new hardware
> >> features that the kernel may know about.  If the kernel enables
> >> new features by default then the tool may fail.  Thus the default
> >> value has to be under the control of the tools not the kernel, so
> >> a sysfs alias will not work.
> >>
> > 
> > I dont follow, could u provide some example?
> 
> Imagine that the 'tsc' term did not exist.  Intel PT trace data
> would not contain TSC packets, and the decoder would not know how to
> decode them.  Then imagine that a new version of the hardware adds
> 'tsc'.  It is such a useful feature that we want it by default, but
> older versions of the tools don't know how to decode it, so the
> kernel cannot turn it on by default.
> 
> > 
> > why the tool needs to understand.. it will just take the alias
> > and apply/use it? The alias follows the format logic, which tells
> > how to apply values on perf_event_attr.. and the kernel knows best
> > what's supported in its version..
> 
> It is similar to why the kernel does not select mmap2 by default.  The
> kernel doesn't know whether the tool supports it.
> 

ook, could you please add some kind of this explanation to the changelog?

thanks,
jirka
--
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