Re: [PATCH] perf: revert PERF_RECORD_MMAP2 support

[Ingo Molnar <mingo@kernel.org>]

* Stephane Eranian <eranian@google.com> wrote:

> 
> This unified patch removes the following commits
> for both kernel and perf tool:
> 
> 6adb0b0 perf tools: Add default handler for mmap2 events
> 384c671 perf trace: Add mmap2 handler
> 5c5e854 perf tools: Add attr->mmap2 support
> d008d52 perf: Fix up MMAP2 buffer space reservation
> 13d7a24 perf: Add attr->mmap2 attribute to an event
> 
> The MMAP2 record extension is not quite ready for prime time.
> We have identified address space cases where mappings would
> not be reported properly when apps fiddled directly with clone()
> and VM_CLONE. We will revisit the patch series soon.
> 
> Signed-off-by: Stephane Eranian <eranian@google.com>
> ---
>  include/uapi/linux/perf_event.h |   24 +----------------
>  kernel/events/core.c            |   47 +++-----------------------------
>  tools/perf/builtin-annotate.c   |    1 -
>  tools/perf/builtin-inject.c     |   15 -----------
>  tools/perf/builtin-mem.c        |    1 -
>  tools/perf/builtin-report.c     |    1 -
>  tools/perf/builtin-script.c     |    1 -
>  tools/perf/builtin-trace.c      |    1 -
>  tools/perf/tests/perf-record.c  |   15 +++--------
>  tools/perf/util/build-id.c      |    1 -
>  tools/perf/util/event.c         |   56 +++++++++------------------------------
>  tools/perf/util/event.h         |   19 -------------
>  tools/perf/util/evsel.c         |   16 +++--------
>  tools/perf/util/header.c        |    3 ---
>  tools/perf/util/machine.c       |   53 +-----------------------------------
>  tools/perf/util/machine.h       |    1 -
>  tools/perf/util/map.c           |    8 +-----
>  tools/perf/util/map.h           |    8 ++----
>  tools/perf/util/session.c       |   27 +------------------
>  tools/perf/util/tool.h          |    1 -
>  20 files changed, 30 insertions(+), 269 deletions(-)

Ugh, that's way too large.

I thought the plan was to do a minimal revert. Is there really no way to 
do this in a (much) shorter fashion?

For example by a simple patch that returns -EINVAL (or -ENOSYS) if the new 
flag is used - i.e. behaves like the old kernel in that regard - but 
leaves the rest in place. (the 'rest' will hopefully be fixed for v3.13)

Tooling will then fall back as if it was an old kernel - i.e. no changes 
needed there at all. Right?

Hm?

	Ingo