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
| ||
|
Date: Tue, 05 Jul 2011 10:51:45 +0200 From: Peter Zijlstra <a.p.zijlstra@...llo.nl> To: Robert Richter <robert.richter@....com> Cc: Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>, 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 On Mon, 2011-07-04 at 19:59 +0200, Robert Richter wrote: > First of all, it follows the idea of grouping events. Attaching events > to a specific pmu is not different from attaching them to a specific > event group. It is actually the same if we think of one group for > events that may be scheduled on only one pmu. Thus, treating a pmu > like a group event is the logical step for intuitive usage of the > perf_open syscall. This way we have symmetrical implementations for > binding events to groups or pmus. That's not a good analogy. Grouping is about events being together, not about events being on a particular pmu. > Device nodes are the general approach for controlling devices from > user-space, they are integral part of the Linux device driver model. > With a device file descriptor opened from a device node we can > explicitly point to a pmu device. Yeah, but we already have a /sys interface, so this ship has sailed. > Representing a device with a device node is common programming > practice. Usage of device nodes is not deprecated. There are existing > frameworks to easily create such devices. With dynamically device node > allocation and udev there are solutions for drawbacks of /dev. Why not > having a device node for pmus? What are your concerns using /dev? Its impossible to represent events using that /dev interface, furthermore we already have a /sys interface, so this is pure duplication of a > The implementation only needs about 150 lines of kernel code. It is > straight and separated. There is nothing special what makes it hard to > read or maintain. The code is using typical kernel device allocation > methods. Do you think this patch makes kernel code too complex? It adds a redundant interface. > Beside of that, using /sys/ is racy. There is no protection against > unregistering the pmu. Probably this might not cause big problems in > practice, but it can be done better. With open/close we can protect > the pmu from being removed. Why can't the open/close of the sysfs file provide the same? It just means you have to close after sys_perf_event_open() > 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. -- 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