All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Ashford <cjashfor@linux.vnet.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Paul Mackerras <paulus@samba.org>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] perf_counter: extensible perf_counter_attr
Date: Mon, 08 Jun 2009 17:50:14 -0700	[thread overview]
Message-ID: <4A2DB1C6.6090209@linux.vnet.ibm.com> (raw)
In-Reply-To: <20090608215002.GB22049@elte.hu>

Ingo Molnar wrote:
> * Corey Ashford <cjashfor@linux.vnet.ibm.com> wrote:
> 
>> Peter Zijlstra wrote:
>>> On Mon, 2009-06-08 at 14:18 -0700, Corey Ashford wrote:
>>>> pca.ext_attrs = &feature.head; /* secretly know that there's data 
>>>> that lies past the attr struct header */
>>> Right, except its not so very secret since we have the type field
>>> telling us.
>> I see.  Thanks for the explanation.  Looks like a good plan to me!
> 
> i think we'd have a much simpler implementation by changing 
> __reserved_1 to attr_size. When the kernel adds new attributes, the 
> size will increase - old user-space will use the old size which the 
> kernel detects and adopts to (by zeroing out that attribute space).
> 
> That way we'll always have a nice flat attributes structure, with no 
> quirky chaining that has field-dependent data types ...
> 
> 	Ingo

If I understand you correctly, you would simply make perf_counter_attr larger 
every time you want to add a new attribute.  Users using the new attributes 
would call sys_perf_counter_open with a larger attr_size value.

What about arch-dependent attributes?  Would you want to place them all in the 
perf_counter_attr struct?  I suppose this could be done by #include'ing an 
arch-specific .h file.

- Corey


  reply	other threads:[~2009-06-09  0:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-08 17:25 [PATCH] perf_counter: extensible perf_counter_attr Peter Zijlstra
2009-06-08 19:02 ` Corey Ashford
2009-06-08 19:51   ` Peter Zijlstra
2009-06-08 21:18     ` Corey Ashford
2009-06-08 21:23       ` Peter Zijlstra
2009-06-08 21:29         ` Corey Ashford
2009-06-08 21:50           ` Ingo Molnar
2009-06-09  0:50             ` Corey Ashford [this message]
2009-06-09  6:51               ` Ingo Molnar
2009-06-09  8:13                 ` Corey Ashford
2009-06-09 11:53                   ` Ingo Molnar
2009-06-09 16:44                     ` Corey Ashford
2009-06-09 22:00                       ` Ingo Molnar
2009-06-09 23:16                         ` Corey Ashford
2009-06-10  0:14                           ` Paul Mackerras
2009-06-10 22:06                             ` Corey Ashford
2009-06-09  4:17 ` Paul Mackerras
2009-06-09  6:53   ` Ingo Molnar
2009-06-09  9:58     ` Paul Mackerras

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=4A2DB1C6.6090209@linux.vnet.ibm.com \
    --to=cjashfor@linux.vnet.ibm.com \
    --cc=acme@ghostprotocols.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --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.