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: <20110705091252.GA5725@elte.hu>
Date:	Tue, 5 Jul 2011 11:12:52 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Robert Richter <robert.richter@....com>,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] [PATCH] perf: Attaching an event to a specific PMU


* Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:

> > Overall, my approach improves the perf design. It adds a better 
> > and more intuitve access to perf from user space with clear and 
> > common methods and interfaces. Please let me know the concerns 
> > you have.
> 
> Its redundant, this interface ship has sailed, its not going to 
> happen.

Even if we had the choice, i don't see how a /dev based enumeration 
of PMUs is in any way better than a topologically attached set of 
PMUs in /sys.

This kind of structure is nice in principle:

 # ls -l /dev/pmu/
 total 0
 crw-rw---- 1 root root 254, 5 Jul  8  2011 breakpoint
 crw-rw---- 1 root root 254, 4 Jul  8  2011 cpu
 crw-rw---- 1 root root 254, 6 Jul  8  2011 proto
 crw-rw---- 1 root root 254, 1 Jul  8  2011 software
 crw-rw---- 1 root root 254, 2 Jul  8  2011 tracepoint

But it should be done in /sys/. That way for example the graphics 
card:

  00:02.0 VGA compatible controller

should have its events under:

  /sys/devices/pci0000\:00/0000\:00\:02.0/events/

breakpoints could be listed in:

  /sys/devices/system/cpu/cpu0/events/

core kernel software events could be listed in:

  /sys/devices/system/core/events/

tracepoints could be listed in their respective subsystem directories:

  /sys/devices/system/timekeeping/events/    # timer tracepoints
  /sys/devices/system/machinecheck/events/   # the MCE tracepoint

  /sys/kernel/slab/events/                   # SLAB tracepoints

  /sys/kernel/debug/tracing/events/          # the old, legacy location of
                                             # tracepoint events

there should also be a /sys/class/events/ populated with symlinks to 
all their locations.

Then we could transition all events to their respective sysfs 
locations, where they would be easily discoverable and enumerable.

The events would also automatically move (and with time, be 
automatically added) when a new device is added to sysfs.

Peter, there was a patch (from you?) that started doing this kind of 
sysfs enumeration with a class added as well - do you still have it 
or do you have a link to it?

Thanks,

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