public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Zhaolei <zhaolei@cn.fujitsu.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tom Zanussi <tzanussi@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] tracing, boottrace: Move include/trace/boot.h to include/linux/boottrace.h
Date: Tue, 14 Apr 2009 00:24:36 +0200	[thread overview]
Message-ID: <20090413222436.GF8514@elte.hu> (raw)
In-Reply-To: <20090413142531.GC5977@nowhere>


* Frederic Weisbecker <fweisbec@gmail.com> wrote:

> On Mon, Apr 13, 2009 at 11:54:11AM +0800, Zhaolei wrote:
> > Impact: refactor code, no functionality changed
> > 
> > Files in include/trace/ should be definition of tracepoints, and header
> > file for boot trace should put to include/linux/.
> > 
> > Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
> > ---
> 
> Until now I had the opinion that it's good to let every tracing 
> headers to be placed in include/trace/* because they are not 
> useful for anything else than the tracer itself so that we don't 
> encumber include/linux for private things.
> 
> So that we have both tracepoints/trace_events plus the low-level 
> tracers headers in include/trace/*
> 
> I'm not opposite to this change, but seeing this patch and the 
> recent divide of kmemtrace headers, I would like to know the 
> opinion of Ingo and Steven about the strict role of 
> include/trace/* Is it only for tracepoints-like bits, or oslo 
> intended for every private tracing purposes?

The header split itself is probably good to do - to keep the 'pure' 
portions of tracepoint definitions cleanly separated from more 
functional details like kmem tracer initialization.

The move to include/linux/ is indeed more debatable. I think if a 
header says 'footrace.h' in its name, it could easily be in 
include/trace/foo.h instead? Makes for a tidier structure - 
include/linux/ is massively over-crowded already.

Steve, what do you think?

	Ingo

  reply	other threads:[~2009-04-13 22:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-13  3:54 [PATCH 1/2] tracing, boottrace: Move include/trace/boot.h to include/linux/boottrace.h Zhaolei
2009-04-13  3:55 ` [PATCH 2/2] tracing, syscalltrace: Move include/trace/syscall.h to include/linux/syscalltrace.h Zhaolei
2009-04-13 14:28   ` Frederic Weisbecker
2009-04-13 14:25 ` [PATCH 1/2] tracing, boottrace: Move include/trace/boot.h to include/linux/boottrace.h Frederic Weisbecker
2009-04-13 22:24   ` Ingo Molnar [this message]
2009-04-13 23:11     ` Steven Rostedt
2009-04-13 23:28       ` Ingo Molnar
2009-04-13 23:34         ` Steven Rostedt
2009-04-13 23:40           ` Ingo Molnar
2009-04-13 23:51             ` Steven Rostedt
2009-04-13 23:53               ` 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=20090413222436.GF8514@elte.hu \
    --to=mingo@elte.hu \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tzanussi@gmail.com \
    --cc=zhaolei@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox