linux-kernel - Re: [ANNOUNCE][PATCH 0 of 4] zedtrace, a general-purpose binary tracer

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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.0903021033500.4771@gandalf.stny.rr.com>
Date:	Mon, 2 Mar 2009 10:41:52 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Christoph Hellwig <hch@...radead.org>
cc:	Tom Zanussi <tzanussi@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Frédéric Weisbecker <fweisbec@...il.com>
Subject: Re: [ANNOUNCE][PATCH 0 of 4] zedtrace, a general-purpose binary
 tracer

On Sat, 28 Feb 2009, Christoph Hellwig wrote:

> I played with it a bit and I really like the userspace with the
> transport backend and a hakcy script language that many people know
> for post-processing.
> 
> But looking at the kernel portions just shows again that the whole
> tracepoint concept is utterly wrong.  We should not need the
> zed_block.c/zed_sched.c/zed_workqueue.c but instead have those
> tracing points directly annotated in the subsystems like using
> markers, so that's it's self-contained and can be added by modules
> without touching the rest of the kernel.
> 
> I know tracepoints are not your fault, but we really need to sort
> that out for a nice tracing experience.

Christoph,

Have you seen my udpates to the TRACE_EVENT_FORMAT? I based my work off of 
Tom's work here. That is, I liked the way he could do the C style 
recording of events, without the printf parsing.

The difference in my work is that I put all of it into a self contained 
macro called TRACE_EVENT_FORMAT:

For example:

TRACE_EVENT_FORMAT(sched_switch,
        TPPROTO(struct rq *rq, struct task_struct *prev,
                struct task_struct *next),
        TPARGS(rq, prev, next),
        TPFMT("task %s:%d ==> %s:%d",
              prev->comm, prev->pid, next->comm, next->pid),
        TRACE_STRUCT(
                TRACE_FIELD(pid_t, prev_pid, prev->pid)
                TRACE_FIELD(int, prev_prio, prev->prio)
                TRACE_FIELD_SPECIAL(char next_comm[TASK_COMM_LEN],
                                    next_comm,
                                    TPCMD(memcpy(TRACE_ENTRY->next_comm,
                                                 next->comm,
                                                 TASK_COMM_LEN)))
                TRACE_FIELD(pid_t, next_pid, next->pid)
                TRACE_FIELD(int, next_prio, next->prio)
        ),
        TPRAWFMT("prev %d:%d ==> next %s:%d:%d")
        );

I explained all these fields in a prior email, but I added the new 
TRACE_FIELD_SPECIAL here (have not posted it yet).

This one allows you to do something special if a simple assignment is not 
enough.

I used next_comm as an example:

TRACE_FIELD_SPECIAL(type_item, item, cmd)

Where type_item is a full line in a structure (not just the time, but the 
item too). This allows to allocate arrays. The item is the same as the 
item in the type_item, but just the variable name and not the type. The 
cmd is the command to perform to record it. Note, you need to use 
TRACE_ENTRY to access the field.

The last TRPRAWFMT is the trace point raw format that corresponds to the 
structure.

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