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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 26 Nov 2009 09:40:39 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	fweisbec@...il.com, penberg@...helsinki.fi, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perf/core] events: Rename TRACE_EVENT_TEMPLATE() to
 DECLARE_EVENT_CLASS()


* Steven Rostedt <rostedt@...dmis.org> wrote:

> On Thu, 2009-11-26 at 08:16 +0000, tip-bot for Ingo Molnar wrote:
> > Commit-ID:  091ad3658e3c76c5fb05f65bfb64a0246f8f31b5
> > Gitweb:     http://git.kernel.org/tip/091ad3658e3c76c5fb05f65bfb64a0246f8f31b5
> > Author:     Ingo Molnar <mingo@...e.hu>
> > AuthorDate: Thu, 26 Nov 2009 09:04:55 +0100
> > Committer:  Ingo Molnar <mingo@...e.hu>
> > CommitDate: Thu, 26 Nov 2009 09:04:55 +0100
> > 
> > events: Rename TRACE_EVENT_TEMPLATE() to DECLARE_EVENT_CLASS()
> > 
> > It is not quite obvious at first sight what TRACE_EVENT_TEMPLATE
> > does: does it define an event as well beyond defining a template?
> > 
> > To clarify this, rename it to DECLARE_EVENT_CLASS, which follows
> > the various 'DECLARE_*()' idioms we already have in the kernel:
> > 
> >   DECLARE_EVENT_CLASS(class)
> > 
> >     DEFINE_EVENT(class, event1)
> >     DEFINE_EVENT(class, event2)
> >     DEFINE_EVENT(class, event3)
> > 
> > To complete this logic we should also rename TRACE_EVENT() to:
> > 
> >   DEFINE_SINGLE_EVENT(single_event)
> > 
> > ... but in a more quiet moment of the kernel cycle.
> 
> 
> I would like to hear what others think about this change before we go 
> ahead and implement it.

You mean TRACE_EVENT() -> DEFINE_SINGLE_EVENT()? Sure, we want todo it 
in a more quiet moment of the kernel cycle, not now.

(TRACE_EVENT_TEMPLATE OTOH has existed for just a few days so it's not a 
problem.)

> A lot of developers have just learned about TRACE_EVENT and now it 
> just disappeared. Well, not really, but in the sense of ' find 
> linux.git -name '*.[ch]' | xargs grep TRACE_EVENT' it no longer 
> exists.

A second problem with the TRACE_EVENT name is that it's not just for 
tracing - we dont necessarily 'trace' events here. We can use the event 
callbacks to collect pure counts:

| aldebaran> perf stat -e sched:sched_wakeup ./hackbench 10
| Time: 0.093
|
|  Performance counter stats for './hackbench 10':
|
|           15481  sched:sched_wakeup      
|
|     0.107390574  seconds time elapsed

etc.

A third problem is that the name 'TRACE_EVENT' does not tell us what is 
being done. Do we declare it? Do we also define it?

DEFINE_SINGLE_EVENT() solves all these problems:

 - It's obvious what it does

 - It suggests users of it that there's another non-single-event 
   facility, gently nudging them towards the use of the more efficient
   DEFINE_EVENT_CLASS() + DEFINE_EVENT() method.

 - It fits nicely into the rest of the naming scheme.

	Ingo
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ