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
| ||
|
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/
Powered by blists - more mailing lists