All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Borislav Petkov <bp@amd64.org>
Cc: Ingo Molnar <mingo@elte.hu>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	osrc-patches <osrc-patches@elbe.amd.com>
Subject: Re: [RFC PATCH] perf: Carve out cgroup-related code
Date: Thu, 12 May 2011 10:51:17 +0200	[thread overview]
Message-ID: <1305190277.2914.259.camel@laptop> (raw)
In-Reply-To: <20110511170912.GA27362@aftab>

On Wed, 2011-05-11 at 19:09 +0200, Borislav Petkov wrote:

I can't really say I like this move stuff into perf_event.h and then
move it out again dance. Makes it exceedingly hard for me to tell wth
actually happened.

>  include/linux/perf_event.h |  132 --------------------------------------------

Compared with:

 include/linux/perf_event.h |  126 +++++++++++-
 include/linux/perf_event.h |    7 +-

Its very hard to tell if this undoes the exact damage you did earlier.

>  kernel/events/callchain.c  |    3 +
>  kernel/events/cgroup.c     |    2 +
>  kernel/events/core.c       |    2 +
>  kernel/events/internal.h   |  129 +++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 136 insertions(+), 132 deletions(-)
>  create mode 100644 kernel/events/internal.h
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 7978850..6b25452 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -963,7 +963,6 @@ enum event_type_t {
>  #ifdef CONFIG_PERF_EVENTS
>  extern struct list_head pmus;
>  extern int perf_pmu_register(struct pmu *pmu, char *name, int type);
> -extern void perf_pmu_unregister(struct pmu *pmu);

That just doesn't make any sense. If we publish one side of the API we
should also publish the other side.

>  extern int perf_num_counters(void);
>  extern const char *perf_pmu_name(void);
> @@ -985,8 +984,6 @@ perf_event_create_kernel_counter(struct perf_event_attr *attr,
>                                 int cpu,
>                                 struct task_struct *task,
>                                 perf_overflow_handler_t callback);
> -extern u64 perf_event_read_value(struct perf_event *event,
> -                                u64 *enabled, u64 *running);

While not used, that is a valid part of the API.

>  
>  struct perf_sample_data {
>         u64                             type;
> @@ -1152,60 +1149,10 @@ extern int perf_output_begin(struct perf_output_handle *handle,
>                              struct perf_event *event, unsigned int size,
>                              int nmi, int sample);
>  extern void perf_output_end(struct perf_output_handle *handle);
> -extern void perf_output_copy(struct perf_output_handle *handle,
> -                            const void *buf, unsigned int len);

idem

>  extern int perf_swevent_get_recursion_context(void);
> -extern void perf_swevent_put_recursion_context(int rctx);

Again, creating asymmetry. 

>  extern void perf_event_enable(struct perf_event *event);
>  extern void perf_event_disable(struct perf_event *event);
>  extern void perf_event_task_tick(void);



  reply	other threads:[~2011-05-12  8:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-11 12:11 [RFC PATCH] perf: Carve out cgroup-related code Borislav Petkov
2011-05-11 13:46 ` Peter Zijlstra
2011-05-11 14:00   ` Ingo Molnar
2011-05-11 14:02   ` Borislav Petkov
2011-05-11 14:13     ` Ingo Molnar
2011-05-11 14:31       ` Borislav Petkov
2011-05-11 15:21         ` Ingo Molnar
2011-05-11 17:09           ` Borislav Petkov
2011-05-12  8:51             ` Peter Zijlstra [this message]
2011-05-12  8:54               ` Peter Zijlstra
2011-05-12 10:18               ` Borislav Petkov
2011-05-12 14:31                 ` Frederic Weisbecker
2011-05-12 15:13                   ` Lin Ming
2011-05-14  8:44                   ` Borislav Petkov
2011-05-14 13:02                     ` Frederic Weisbecker
2011-05-12 10:36             ` Ingo Molnar
2011-05-12 10:54               ` Borislav Petkov
2011-05-12 11:03                 ` Ingo Molnar

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=1305190277.2914.259.camel@laptop \
    --to=a.p.zijlstra@chello.nl \
    --cc=bp@amd64.org \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=osrc-patches@elbe.amd.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 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.