Re: collecting static data related to tracing

[Frederic Weisbecker <fweisbec@gmail.com>]

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.