linux-kernel - Re: [RFC] tracefs

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: <1256303528.20866.822.camel@gandalf.stny.rr.com>
Date:	Fri, 23 Oct 2009 09:12:08 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Greg KH <greg@...ah.com>, Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RFC] tracefs

On Fri, 2009-10-23 at 07:32 +0200, Ingo Molnar wrote:

> _No way_ do we want to tie down the pretty-printing ftrace details as an 
> ABI. We promised that when ftrace went upstream and all the details are 
> way too messy to be exposed in an ABI alike matter (and yes, consider 
> this a NAK Steve ;-).

Note, I wasn't talking about tie down the pretty-print formats. But we
need to have a standard way to change them.

For example:

[root@mxf ~]# cat /debug/tracing/events/power/power_start/format 
name: power_start
ID: 258
format:
	field:unsigned short common_type;	offset:0;	size:2;
	field:unsigned char common_flags;	offset:2;	size:1;
	field:unsigned char common_preempt_count;	offset:3;	size:1;
	field:int common_pid;	offset:4;	size:4;
	field:int common_lock_depth;	offset:8;	size:4;

	field:u64 type;	offset:16;	size:8;
	field:u64 state;	offset:24;	size:8;

print fmt: "type=%lu state=%lu", (unsigned long)REC->type, (unsigned long)REC->state


Now we are going to add a "signed" field to each line. Fine, but we need
a spec of some sort to say how that will happen. Or what can be expected
to not change. We can say the type (field in this case) will always be
the first item, and that the type will stay on a single line. If the
parser does not know how to handle one of the items (offset, size, etc)
it can simply ignore it. When it hits the "\n", it is done with that
type.

We need to document this, so tools will not break when we update this
format.

-- Steve


--
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/