linux-kernel - perf: allow command to attach local data to thread/evsel structs

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-next>] [day] [month] [year] [list]

Message-ID: <4F316964.2050900@gmail.com>
Date:	Tue, 07 Feb 2012 11:11:48 -0700
From:	David Ahern <dsahern@...il.com>
To:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Stephane Eranian <eranian@...gle.com>
CC:	LKML <linux-kernel@...r.kernel.org>
Subject: perf: allow command to attach local data to thread/evsel structs

This is an API I have been using for some 'local' commands that process
perf events. It allows the commands to attach data to events and threads
and avoid local caching and lookups.


diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 326b8e4..866de40 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -66,6 +66,12 @@ struct perf_evsel {
        void        *data;
    } handler;
    bool            supported;
+
+   /*
+    * can be used by commands that process samples
+    * for storing local, event-based data
+    */
+   void *private;
 };

 struct cpu_map;
diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h
index 70c2c13..9f62859 100644
--- a/tools/perf/util/thread.h
+++ b/tools/perf/util/thread.h
@@ -16,6 +16,12 @@ struct thread {
    bool            comm_set;
    char            *comm;
    int         comm_len;
+
+    /*
+    * can be used by commands that process samples
+    * for storing local, thread-based data
+    */
+   void *private;
 };

 struct machine;

One wrinkle is that for the thread-based one the thread__delete(),
thread__fork() and thread__set_comm() functions would free the
allocations if set -- or a handler is needed to free private structs to
handle layered mallocs.

Any objections to pushing this kind of open-ended API into perf?

David
--
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/