From: Leo Yan <leo.yan@linaro.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Ian Rogers <irogers@google.com>, Andi Kleen <ak@linux.intel.com>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>, Jiri Olsa <jolsa@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH v4 1/2] perf parse: Refactor struct perf_evsel_config_term
Date: Mon, 13 Jan 2020 23:21:03 +0800 [thread overview]
Message-ID: <20200113152103.GC10620@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <20200110150410.GG82989@krava>
On Fri, Jan 10, 2020 at 04:04:10PM +0100, Jiri Olsa wrote:
> On Thu, Jan 09, 2020 at 09:34:24AM -0700, Mathieu Poirier wrote:
>
> SNIP
>
> >
> > If we are to deal with all flields of the union, I think it should be as below:
> >
> > union {
> > bool cfg_bool;
> > int cfg_int;
> > unsigned long cfg_ulong;
> > u32 cfg_u32;
> > char *cfg_str;
> > } val;
> >
> > But just dealing with the "char *" as below would also be fine with me:
> >
> > union {
> > u64 period;
> > u64 freq;
> > bool time;
> > u64 stack_user;
> > int max_stack;
> > bool inherit;
> > bool overwrite;
> > unsigned long max_events;
> > bool percore;
> > bool aux_output;
> > u32 aux_sample_size;
> > u64 cfg_chg;
> > u64 num;
> > char *str;
> > } val;
> >
> > >
> > > struct perf_evsel_config_term {
> > > struct list_head list;
> > > enum evsel_term_type type;
> > > union {
> > > u64 period;
> > > u64 freq;
> > > bool time;
> > > char *callgraph;
> > > char *drv_cfg;
> > > u64 stack_user;
> > > int max_stack;
> > > bool inherit;
> > > bool overwrite;
> > > char *branch;
> > > unsigned long max_events;
> > > bool percore;
> > > bool aux_output;
> > > u32 aux_sample_size;
> > > u64 cfg_chg;
> > > + u64 num;
> > > + char *str;
> > > } val;
> > > bool weak;
> > > };
> > >
> > > > I will let Jiri make the
> > > > final call but if we are to proceed this way I think we should have a
> > > > member per type to avoid casting issues.
> > >
> > > Yeah, let's see what's Jiri thinking.
> > >
> > > Just note, with this change, I don't see any casting warning or errors
> > > when built perf on arm64/arm32.
> >
> > At this time you may not, but they will happen and it will be very hard to
> > debug.
>
> hi,
> sry for late reply..
>
> I think ;-) we should either add all different types to the union
> or just add 'str' pointer to handle strings correctly.. which seems
> better, because it's less changes and there's no real issue that
> would need that other bigger change
Thanks for the suggestion, Jiri.
Have sent out patch v5 with following the ideas.
Thanks,
Leo Yan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Leo Yan <leo.yan@linaro.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Jiri Olsa <jolsa@kernel.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andi Kleen <ak@linux.intel.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mike Leach <mike.leach@linaro.org>
Subject: Re: [PATCH v4 1/2] perf parse: Refactor struct perf_evsel_config_term
Date: Mon, 13 Jan 2020 23:21:03 +0800 [thread overview]
Message-ID: <20200113152103.GC10620@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <20200110150410.GG82989@krava>
On Fri, Jan 10, 2020 at 04:04:10PM +0100, Jiri Olsa wrote:
> On Thu, Jan 09, 2020 at 09:34:24AM -0700, Mathieu Poirier wrote:
>
> SNIP
>
> >
> > If we are to deal with all flields of the union, I think it should be as below:
> >
> > union {
> > bool cfg_bool;
> > int cfg_int;
> > unsigned long cfg_ulong;
> > u32 cfg_u32;
> > char *cfg_str;
> > } val;
> >
> > But just dealing with the "char *" as below would also be fine with me:
> >
> > union {
> > u64 period;
> > u64 freq;
> > bool time;
> > u64 stack_user;
> > int max_stack;
> > bool inherit;
> > bool overwrite;
> > unsigned long max_events;
> > bool percore;
> > bool aux_output;
> > u32 aux_sample_size;
> > u64 cfg_chg;
> > u64 num;
> > char *str;
> > } val;
> >
> > >
> > > struct perf_evsel_config_term {
> > > struct list_head list;
> > > enum evsel_term_type type;
> > > union {
> > > u64 period;
> > > u64 freq;
> > > bool time;
> > > char *callgraph;
> > > char *drv_cfg;
> > > u64 stack_user;
> > > int max_stack;
> > > bool inherit;
> > > bool overwrite;
> > > char *branch;
> > > unsigned long max_events;
> > > bool percore;
> > > bool aux_output;
> > > u32 aux_sample_size;
> > > u64 cfg_chg;
> > > + u64 num;
> > > + char *str;
> > > } val;
> > > bool weak;
> > > };
> > >
> > > > I will let Jiri make the
> > > > final call but if we are to proceed this way I think we should have a
> > > > member per type to avoid casting issues.
> > >
> > > Yeah, let's see what's Jiri thinking.
> > >
> > > Just note, with this change, I don't see any casting warning or errors
> > > when built perf on arm64/arm32.
> >
> > At this time you may not, but they will happen and it will be very hard to
> > debug.
>
> hi,
> sry for late reply..
>
> I think ;-) we should either add all different types to the union
> or just add 'str' pointer to handle strings correctly.. which seems
> better, because it's less changes and there's no real issue that
> would need that other bigger change
Thanks for the suggestion, Jiri.
Have sent out patch v5 with following the ideas.
Thanks,
Leo Yan
next prev parent reply other threads:[~2020-01-13 15:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-08 14:20 [PATCH v4 1/2] perf parse: Refactor struct perf_evsel_config_term Leo Yan
2020-01-08 14:20 ` Leo Yan
2020-01-08 14:20 ` [PATCH v4 2/2] perf parse: Copy string to perf_evsel_config_term Leo Yan
2020-01-08 14:20 ` Leo Yan
2020-01-08 17:58 ` [PATCH v4 1/2] perf parse: Refactor struct perf_evsel_config_term Mathieu Poirier
2020-01-08 17:58 ` Mathieu Poirier
2020-01-09 5:08 ` Leo Yan
2020-01-09 5:08 ` Leo Yan
2020-01-09 16:34 ` Mathieu Poirier
2020-01-09 16:34 ` Mathieu Poirier
2020-01-10 15:04 ` Jiri Olsa
2020-01-10 15:04 ` Jiri Olsa
2020-01-13 15:21 ` Leo Yan [this message]
2020-01-13 15:21 ` Leo Yan
2020-01-10 15:04 ` Jiri Olsa
2020-01-10 15:04 ` Jiri Olsa
2020-01-13 15:22 ` Leo Yan
2020-01-13 15:22 ` Leo Yan
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=20200113152103.GC10620@leoy-ThinkPad-X240s \
--to=leo.yan@linaro.org \
--cc=acme@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.