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

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]

Message-ID: <op.ubla5cik03j166@prasadkr_t60p.in.ibm.com>
Date:	Fri, 23 May 2008 10:07:50 +0530
From:	"K.Prasad" <prasad@...ux.vnet.ibm.com>
To:	"Andrew Morton" <akpm@...ux-foundation.org>, zanussi@...cast.net
Cc:	prasad@...ux.vnet.ibm.com, 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 Tue, May 20, 2008 at 01:12:25PM -0700, Andrew Morton wrote:
> 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.
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/