Re: [RFC Patch 1/1] trace_printk and trace_dump interface - v2

From: K.Prasad
Date: Fri May 23 2008 - 00:38:23 EST


On Tue, May 20, 2008 at 01:12:25PM -0700, Andrew Morton wrote:
On Wed, 21 May 2008 01:23:09 +0530
"K.Prasad" <prasad@xxxxxxxxxxxxxxxxxx> 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.
Since "trace_*" uses relay infrastructure underneath, I am thinking, if it
would be acceptable to rename them to "relay_*", say relay_printk() and
relay_dump(). I would be glad to hear from the 'relay' folks about this
thought.

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.
More than a tracing mechanism, this is a tool that aids in tracing, by
providing a powerful function that directs its output onto the debugfs
mount path which could be later harnessed by user-space applications
too. A potential in-kernel user could be the 'marker' handlers which
more often would be interested in logging data.

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.

Among the other enhancements that we were contemplating for this
mechanism, to make it more powerful and unique, is the ability to
a)Define callback functions typically invoked everytime before accessing/
printing each variable (which may say, acquire a lock or prefix a
timestamp) by adding fields to the trace_printk_data structure.
b)Provide sequencing information for the output, along with ability to
prefix the output with essential data such as PID, Timestamp, CPUID,
etc.

Thanks for letting us know your thoughts on this.

--K.Prasad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/