Commit-ID:  069c1c6cc3646454f9c8e83084a25f8eb8cab7ae
Gitweb:     https://git.kernel.org/tip/069c1c6cc3646454f9c8e83084a25f8eb8cab7ae
Author:     Arnaldo Carvalho de Melo <a...@redhat.com>
AuthorDate: Tue, 18 Dec 2018 11:49:58 -0300
Committer:  Arnaldo Carvalho de Melo <a...@redhat.com>
CommitDate: Tue, 18 Dec 2018 16:17:41 -0300

perf beauty: Add generator for fadvise64's 'advice' arg constants

  $ tools/perf/trace/beauty/fadvise.sh
  static const char *fadvise_advices[] = {
        [0] = "NORMAL",
        [1] = "RANDOM",
        [2] = "SEQUENTIAL",
        [3] = "WILLNEED",
        [4] = "DONTNEED",
        [5] = "NOREUSE",
  };
  $

This has a hack wrt the s390 difference.

Cc: Adrian Hunter <adrian.hun...@intel.com>
Cc: Jiri Olsa <jo...@kernel.org>
Cc: Luis Cláudio Gonçalves <lclau...@redhat.com>
Cc: Namhyung Kim <namhy...@kernel.org>
Cc: Wang Nan <wangn...@huawei.com>
Link: https://lkml.kernel.org/n/tip-tb7jguv01u8p570piq13e...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
---
 tools/perf/trace/beauty/fadvise.sh | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/tools/perf/trace/beauty/fadvise.sh 
b/tools/perf/trace/beauty/fadvise.sh
new file mode 100755
index 000000000000..b15ae3875167
--- /dev/null
+++ b/tools/perf/trace/beauty/fadvise.sh
@@ -0,0 +1,22 @@
+#!/bin/sh
+# SPDX-License-Identifier: LGPL-2.1
+
+[ $# -eq 1 ] && header_dir=$1 || header_dir=tools/include/uapi/linux/
+
+printf "static const char *fadvise_advices[] = {\n"
+regex='^[[:space:]]*#[[:space:]]*define[[:space:]]+POSIX_FADV_(\w+)[[:space:]]+([[:digit:]]+)[[:space:]]+.*'
+
+egrep $regex ${header_dir}/fadvise.h | \
+       sed -r "s/$regex/\2 \1/g"       | \
+       sort | xargs printf "\t[%s] = \"%s\",\n" | \
+       grep -v "[6].*DONTNEED" | grep -v "[7].*NOREUSE"
+printf "};\n"
+
+# XXX Fix this properly:
+
+# The grep 6/7 DONTNEED/NOREUSE are a hack to filter out the s/390 oddity See
+# tools/include/uapi/linux/fadvise.h for details.
+
+# Probably fix this when generating the string tables per arch so that We can
+# reliably process on arch FOO a perf.data file collected by 'perf trace
+# record' on arch BAR, e.g. collect on s/390 and process on x86.

Reply via email to