linux-kernel - Re: collecting static data related to tracing

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: <20100519072838.GD5704@nowhere>
Date:	Wed, 19 May 2010 09:28:39 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	rostedt@...dmis.org, linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: collecting static data related to tracing

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/