public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: He Kuang <hekuang@huawei.com>
Cc: peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
	alexander.shishkin@linux.intel.com, wangnan0@huawei.com,
	jpoimboe@redhat.com, ak@linux.intel.com, eranian@google.com,
	namhyung@kernel.org, adrian.hunter@intel.com,
	sukadev@linux.vnet.ibm.com, masami.hiramatsu.pt@hitachi.com,
	tumanova@linux.vnet.ibm.com, kan.liang@intel.com,
	penberg@kernel.org, dsahern@gmail.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 3/5] perf callchain: Add support for cross-platform unwind
Date: Thu, 26 May 2016 19:42:55 +0200	[thread overview]
Message-ID: <20160526174255.GA11246@krava> (raw)
In-Reply-To: <1464081629-137191-4-git-send-email-hekuang@huawei.com>

On Tue, May 24, 2016 at 09:20:27AM +0000, He Kuang wrote:
> Use thread specific unwind ops to unwind cross-platform callchains.
> 
> Currently, unwind methods is suitable for local unwind, this patch
> changes the fixed methods to thread/map related. Each time a map is
> inserted, we find the target arch and see if this platform can be
> remote unwind. We test for x86 platform and only show proper
> messages. The real unwind methods are not implemented, will be
> introduced in next patch.
> 
> CONFIG_LIBUNWIND/NO_LIBUNWIND are changed to
> CONFIG_LOCAL_LIBUNWIND/NO_LOCAL_LIBUNWIND for retaining local unwind
> features. CONFIG_LIBUNWIND stands for either local or remote or both
> unwind are supported and NO_LIBUNWIND means neither local nor remote
> libunwind are supported.

hi,
I think this is too complex and error prone, I'd rather see it split
to several pieces. Basically every logicaly single piece should be
in separate patch for better readablebility and review.

I might be missing some but I'd mainly sepatate following:

  - introducing struct unwind_libunwind_ops for local unwind
  - moving unwind__prepare_access from thread_new into thread__insert_map
  - keep unwind__prepare_access name instead of unwind__get_arch
    and keep the return value, we need to bail out in case of error
  - I wouldn't use null ops.. just check for for ops == NULL in wrapper function

  - I understand we need to compile 3 objects from unwind-libunwind.c,
    how about we create 3 files like:

    util/unwind-libunwind-local.c
    util/unwind-libunwind-x86_32.c
    util/unwind-libunwind-arm64.c

    which would setup all necessary defines and include unwind-libunwind.c like:

    ---
    /* comments explaining every define ;-) */
    ...
    #define LOCAL... REMOTE..
    ...
    #include <util/unwind-libunwind-local.c>
    ...
    ----

    this way we will keep all the special setup for given unwind object
    in one place and you can also use simple rule in the Build file like
    without defining special rule:

    libperf-$(CONFIG_LIBUNWIND_X86)      += unwind-libunwind_x86_32.o
    libperf-$(CONFIG_LIBUNWIND_AARCH64)  += unwind-libunwind_arm64.o

    the same way for the arch object:

    arch/x86/util/unwind-libunwind-local.c
    arch/x86/util/unwind-libunwind-x86_32.c


Not sure I thought everything through, but I think this way
we'll keep it more maintainable and readable..

let me know what you think

thanks,
jirka

  reply	other threads:[~2016-05-26 17:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-24  9:20 [PATCH v5 0/5] Add support for remote unwind He Kuang
2016-05-24  9:20 ` [PATCH v5 1/5] perf tools: Use LIBUNWIND_DIR for remote libunwind feature check He Kuang
2016-05-24  9:20 ` [PATCH v5 2/5] perf tools: Show warnings for unsupported cross-platform unwind He Kuang
2016-05-24  9:20 ` [PATCH v5 3/5] perf callchain: Add support for " He Kuang
2016-05-26 17:42   ` Jiri Olsa [this message]
2016-05-27  7:13     ` Hekuang
2016-05-27  7:38       ` Jiri Olsa
2016-05-27  8:02         ` Hekuang
2016-05-27  8:44           ` Jiri Olsa
2016-05-26 17:51   ` Jiri Olsa
2016-05-24  9:20 ` [PATCH v5 4/5] perf callchain: Support x86 target platform He Kuang
2016-05-26 17:57   ` Jiri Olsa
2016-05-24  9:20 ` [PATCH v5 5/5] perf callchain: Support aarch64 cross-platform He Kuang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160526174255.GA11246@krava \
    --to=jolsa@redhat.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=dsahern@gmail.com \
    --cc=eranian@google.com \
    --cc=hekuang@huawei.com \
    --cc=jpoimboe@redhat.com \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=penberg@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sukadev@linux.vnet.ibm.com \
    --cc=tumanova@linux.vnet.ibm.com \
    --cc=wangnan0@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox