Re: collecting static data related to tracing

From: Frederic Weisbecker
Date: Wed May 19 2010 - 03:28:41 EST

On Tue, May 18, 2010 at 04:45:09PM +0200, Johannes Berg wrote:
> On Tue, 2010-05-18 at 10:41 -0400, Steven Rostedt wrote:
> > The latest version of trace-cmd has an "options" section. This allows
> > you to add options to the file.
> >
> > We could make a plugin that also can be used by trace-cmd record, that
> > allows you to add options. The options are written such that if a
> > trace-cmd does not know how to deal with them, they will be ignored.
> >
> > Hmm, but the options require a unique ID. Well we could register IDs
> > with plugins, or add a plugin id, which uses the name of the plugin as
> > an identifier too.
> >
> > But this would allow you to add the details you want about the system
> > and then have the reader be able to print it out.
> >
> > How's that sound?
> Sounds good, although it does require that I tell people who want to
> record to also install the recording plugin, but that should be
> manageable :) I can just dig out the data from the regular debugfs once
> I add files containing it.
> johannes

This is a place where events injection might be suitable perhaps.
Either kernel or user space event injection.

kernel space injection would be a simple trace event declared that
have a callback called when it gets enabled. This callback would
inject any events it wants.

userspace injection could be a bit different, the user can inject
its own format and events content toward a debugfs or whatever file.
This would be suitable if userspace have few things to inject,
otherwise we would need to think about something else perhaps.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at