lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 05 Mar 2014 16:05:53 -0800 From: Cody P Schafer <cody@...ux.vnet.ibm.com> To: Michael Ellerman <mpe@...erman.id.au>, Linux PPC <linuxppc-dev@...ts.ozlabs.org>, Arnaldo Carvalho de Melo <acme@...stprotocols.net>, Ingo Molnar <mingo@...hat.com>, Paul Mackerras <paulus@...ba.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl> CC: Peter Zijlstra <peterz@...radead.org>, LKML <linux-kernel@...r.kernel.org>, scottwood@...escale.com Subject: Re: [PATCH v3 02/11] perf: add PMU_FORMAT_RANGE() helper for use by sw-like pmus On 03/04/2014 12:09 AM, Cody P Schafer wrote: > On 03/03/2014 09:19 PM, Michael Ellerman wrote: >> On Thu, 2014-27-02 at 21:04:55 UTC, Cody P Schafer wrote: >>> Add PMU_FORMAT_RANGE() and PMU_FORMAT_RANGE_RESERVED() (for reserved >>> areas) which generate functions to extract the relevent bits from >>> event->attr.config{,1,2} for use by sw-like pmus where the >>> 'config{,1,2}' values don't map directly to hardware registers. >>> >>> Signed-off-by: Cody P Schafer <cody@...ux.vnet.ibm.com> >>> --- >>> include/linux/perf_event.h | 17 +++++++++++++++++ >>> 1 file changed, 17 insertions(+) >>> >>> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h >>> index e56b07f..3da5081 100644 >>> --- a/include/linux/perf_event.h >>> +++ b/include/linux/perf_event.h >>> @@ -871,4 +871,21 @@ _name##_show(struct device >>> *dev, \ >>> \ >>> static struct device_attribute format_attr_##_name = __ATTR_RO(_name) >>> >>> +#define PMU_FORMAT_RANGE(name, attr_var, bit_start, bit_end) \ >>> +PMU_FORMAT_ATTR(name, #attr_var ":" #bit_start "-" #bit_end); \ >>> +PMU_FORMAT_RANGE_RESERVED(name, attr_var, bit_start, bit_end) >> >> I really think these should have event in the name. >> >> Someone looking at the code is going to see event_get_foo() and wonder >> where >> that is defined. Grep won't find a definition, tags won't find a >> definition, >> the least you can do is have the macro name give some hint. >> > > That is a good point (grep-ability). Let me think about this. There is > also the possibility that I could adjust the event_get_*() naming to > something else. format_get_*()? event_get_format_*()? (these names keep > growing...) > I've gone with a format_get(name, event) style macro (making it more grep-able), in v4. Feel free to direct further discussion to the v4 posting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists