linux-kernel - Re: [PATCH 11/13] android: persistent_trace: ftrace into persistent

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: <20120307221002.GC16652@kroah.com>
Date:	Wed, 7 Mar 2012 14:10:02 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	John Stultz <john.stultz@...aro.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Colin Cross <ccross@...roid.com>,
	Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH 11/13] android: persistent_trace: ftrace into
 persistent_ram

On Wed, Mar 07, 2012 at 01:58:21PM -0800, John Stultz wrote:
> From: Colin Cross <ccross@...roid.com>
> 
> persistent_trace uses the ftrace infrastructure, but traces
> into a persistent_ram buffer instead of the regular ftrace
> ringbuffer.  After a reset or panic, the trace can be
> decoded with cat /sys/kernel/debug/persistent_trace.

Has this patch been run by the tracing kernel developers?

And what's the status on merging the persistent_ram stuff in with the
in-kernel api for this type of thing?  That should then get rid of this
separate tracing module, or at the least, let it be accepted directly by
the tracing developers and not need to go through staging, right?

thanks,

greg k-h
--
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/