linux-kernel - Re: [Patch] Tracing/ftrace: Adds a marker to allow user comments

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: <20080906164909.4b6f3a49@daedalus.pq.iki.fi>
Date:	Sat, 6 Sep 2008 16:49:09 +0300
From:	Pekka Paalanen <pq@....fi>
To:	"Frédéric Weisbecker" <fweisbec@...il.com>
Cc:	"Steven Rostedt" <rostedt@...dmis.org>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [Patch] Tracing/ftrace: Adds a marker to allow user comments

On Sat, 6 Sep 2008 13:39:55 +0200
"Frédéric Weisbecker" <fweisbec@...il.com> wrote:

> 2008/9/4 Steven Rostedt <rostedt@...dmis.org>:
> 
> > For logdev (my pet project from way back, and the latest ftrace is based
> > on), I had a CUSTOM type. The API allowed to register a callback to a
> > type, and it would associate that type to some number (descriptor) and
> > pass that number back to you. Then you could use this number to write to
> > the buffer using the CUSTOM type and registered number. On output, when a
> > CUSTOM type is detected, it would read the custom.id (the number) and
> > search for any registered callbacks to handle the entry.
> >
> > This probably would not be too difficult to implement. Especially since it
> > is already implemented in logdev.
> > (see http://rostedt.homelinux.com/logdev/)
> >
> > -- Steve
> 
> Why not. It is a way for a tracer to handle output for any type of entries.
> But will this feature really be used for other special types than
> TRACE_PRINT? I'm not sure... If it is not the case, the Pekka's
> solution seems to me far more simple.
> 
> But actually I don't know the needs of others tracers...

I never thought TRACE_PRINT would need anything more. At least I'm happy
with the concept of TRACE_PRINT, it just needs some adjustments in the API
to be nice to use.

True, I might some day want to add yet another entry type for mmiotrace,
but I'm not planning that for now, and I could just add it like they are
in the current framework. But the benefit of the CUSTOM type would be
to allow modularized and out-of-tree tracers. And then, why keep the
current predefined types, why not make everything a CUSTOM type? Just
define a block size in the ring buffer and use TRACE_CONT to handle
payload larger than the block.

Anyway, personally I'm satisfied with the current state of the framework
and I can only talk for mmiotrace.


Cheers,
pq

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
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/