[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080520131225.46175b3b.akpm@linux-foundation.org>
Date: Tue, 20 May 2008 13:12:25 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: prasad@...ux.vnet.ibm.com
Cc: linux-kernel@...r.kernel.org, dwilder@...ibm.com, hch@...radead.org
Subject: Re: [RFC Patch 1/1] trace_printk and trace_dump interface - v2
On Wed, 21 May 2008 01:23:09 +0530
"K.Prasad" <prasad@...ux.vnet.ibm.com> wrote:
>
> The name 'trace' (previously GTSC), I gather that it was the chosen after
> much deliberation (http://tinyurl.com/6odoh4), however I'm open to the
> idea of changing the name (say dbg_printk/dbg_dump?).
>
> Kindly let me know of your suggestions for this, and I will change them
> during the next version.
Well I was just putting it out there for consideration. Yes, I think
the whole idea of consuming the "trace_*" namespace in this patchset
was ill-advised.
Also, I don't know how to move forward with the whole feature - I
haven't seen a lot of interest from others and I haven't seen much
discussion of how this feature differs from all the other tracing
things which have been floating about.
And even if the proposed patches presently offer unique and useful
features, will one of the other tracing implementations (eg: ltt) later
grow to close that gap?
I'm also a bit dubious about the whole thing based on past experience
with kernel-developer-only in-kernel tools. People just don't use them
much. One example: fault injection.
> Will something like this look better?
If it addresses the comment I raised, sure. Please satisfy yourself
that it does.
--
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