From: Randy Dunlap <randy.dunlap@oracle.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
systemtap@sources.redhat.com, ltt-dev@shafik.org
Subject: Re: [PATCH] Linux Kernel Markers Documentation
Date: Thu, 15 Feb 2007 17:45:00 -0800 [thread overview]
Message-ID: <20070215174500.2b1b3bb9.randy.dunlap@oracle.com> (raw)
In-Reply-To: <20070216013348.GC12736@Krystal>
On Thu, 15 Feb 2007 20:33:48 -0500 Mathieu Desnoyers wrote:
> Linux Kernel Markers - Documentation
>
> Here is some documentation explaining what is/how to use the Linux
> Kernel Markers.
>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
>
> --- /dev/null
> +++ b/Documentation/marker.txt
> @@ -0,0 +1,130 @@
> + Using the Linux Kernel Markers
> +
> + Mathieu Desnoyers
> +
> +
> + This document discusses the purpose of markers. It shows some usage
> +examples of the Linux Kernel Markers : how to insert markers within the kernel
> +and how to connect probes to a marker. Finally, it has some probe module
> +examples. This is what connects to a marker.
> +
> +
> +* Purpose of markers
> +
> +You can put markers at important locations in the code. They act as
> +lightweight hooks that can pass an arbitrary number of parameters,
> +described in a printk-like format string, to a function whenever the marker
> +code is reached.
> +
> +They can be used for tracing (LTTng, LKET over SystemTAP), overall performance
> +accounting (SystemTAP). They could also be used to implement
> +efficient hooks for SELinux or any other subsystem the would have this
that
> +kind of need.
> +
> +Using the markers for system audit (SELinux) would require to pass a
> +variable by address that would be later checked by the marked routine.
> +
> +
> +* Usage
> +
> +MARK(subsystem_event, "%d %s %p[struct task_struct]",
> + someint, somestring, current);
> +Where :
> +- Subsystem is the name of your subsystem.
> +- event is the name of the event to mark.
so is the MARK() supposed to be:
MARK(subsystem, event, ...
Please make the 2 doc. lines above match the parameters...
or the parameters match the text.
> +- "%d %s %p[struct task_struct]" is the formatted string for (printk-style).
> +- someint is an integer.
> +- somestring is a char pointer.
> +- current is a pointer to a struct task_struct.
> +
> +The expression %p[struct task_struct] is a suggested marker definition
> +standard that could eventually be used for pointer type checking in
> +sparse. The brackets contain the type to which the pointer refer.
refers.
> +
> +The marker mechanism supports multiple instances of the same marker.
> +Markers can be put in inline functions, inlined static functions and
> +unrolled loops.
> +
> +Note : It is safe to put markers within preempt-safe code : preempt_enable()
> +will not call the scheduler due to the tests in preempt_schedule().
> +
> +
> +* Optimization for a given architecture
> +
> +You will find, in asm-*/marker.h, optimisations for given architectures
> +(currently i386 and powerpc). They use a load immediate instead of a data read,
> +which saves a data cache hit, but also requires cross CPU code modification. In
> +order to support embedded systems which use read-only memory for their code, the
> +optimization can be disabled through menu options.
> +
> +
> +* Probe example
> +
> +------------------------------ CUT -------------------------------------
> +/* probe-example.c
> + *
> + * Loads a function at a marker call site.
> + *
> + * (C) Copyright 2007 Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> + *
> + * This file is released under the GPLv2.
> + * See the file COPYING for more details.
> + */
> +
> +#include <linux/sched.h>
> +#include <linux/kernel.h>
> +
> +#define SUBSYSTEM_EVENT_FORMAT "%d %s %p[struct task_struct]"
Is SUBSYSTEM_EVENT_FORMAT used implicitly below? or elsewhere?
> +void probe_subsystem_event(const char *format, ...)
> +{
> + va_list ap;
> + /* Declare args */
> + unsigned int value;
> + const char *mystr;
> + struct task_struct *task;
> +
> + /* Assign args */
> + va_start(ap, format);
> + value = va_arg(ap, typeof(value));
> + mystr = va_arg(ap, typeof(mystr));
> + task = va_arg(ap, typeof(task));
> +
> + /* Call tracer */
> + trace_subsystem_event(value, mystr, task);
> +
> + /* Or call printk */
> + vprintk(format, ap);
> +
> + /* or count, check rights... */
> +
> + va_end(ap);
> +}
> +
> +static int __init probe_init(void)
> +{
> + int result;
> + result = marker_set_probe("subsystem_event",
> + FS_CLOSE_FORMAT,
> + probe_fs_close);
Do FS_CLOSE_FORMAT and probe_fs_close() need to be defined here?
I.e., is this a complete example?
> + if (!result)
> + goto cleanup;
> + return 0;
> +
> +cleanup:
> + marker_remove_probe(probe_subsystem_event);
> + return -EPERM;
> +}
> +
> +static void __exit probe_fini(void)
> +{
> + marker_remove_probe(probe_subsystem_event);
> +}
> +
> +module_init(probe_init);
> +module_exit(probe_fini);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Mathieu Desnoyers");
> +MODULE_DESCRIPTION("SUBSYSTEM Probe");
> +------------------------------ CUT -------------------------------------
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
next prev parent reply other threads:[~2007-02-16 1:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-11 20:03 [PATCH 00/05] Linux Kernel Markers - kernel 2.6.20 Mathieu Desnoyers
2007-02-11 20:03 ` [PATCH 01/05] Linux Kernel Markers : Kconfig menus Mathieu Desnoyers
2007-02-11 20:03 ` [PATCH 02/05] Linux Kernel Markers, architecture independant code Mathieu Desnoyers
2007-02-15 7:21 ` Andrew Morton
2007-02-15 19:12 ` Mathieu Desnoyers
2007-02-11 20:03 ` [PATCH 03/05] Linux Kernel Markers : powerpc optimization Mathieu Desnoyers
2007-02-11 20:03 ` [PATCH 04/05] Linux Kernel Markers : i386 optimization Mathieu Desnoyers
2007-02-11 20:03 ` [PATCH 05/05] Linux Kernel Markers, non optimized architectures Mathieu Desnoyers
2007-02-15 7:16 ` Andrew Morton
2007-02-15 19:09 ` Mathieu Desnoyers
2007-02-16 20:26 ` Karim Yaghmour
2007-02-16 23:38 ` Mathieu Desnoyers
2007-02-21 20:09 ` Karim Yaghmour
2007-02-21 20:45 ` Mathieu Desnoyers
2007-02-21 22:06 ` Karim Yaghmour
2007-02-22 0:18 ` [PATCH] Linux Kernel Markers - cleanup Mathieu Desnoyers
2007-02-15 7:12 ` [PATCH 00/05] Linux Kernel Markers - kernel 2.6.20 Andrew Morton
2007-02-15 15:28 ` Frank Ch. Eigler
2007-02-15 22:18 ` Andrew Morton
2007-02-15 22:30 ` Mathieu Desnoyers
2007-02-15 23:14 ` Vara Prasad
2007-02-16 1:32 ` Mathieu Desnoyers
2007-02-16 1:33 ` [PATCH] Linux Kernel Markers Documentation Mathieu Desnoyers
2007-02-16 1:45 ` Randy Dunlap [this message]
2007-02-16 3:56 ` Mathieu Desnoyers
2007-02-16 4:05 ` [PATCH] Linux Kernel Markers Documentation - fix Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070215174500.2b1b3bb9.randy.dunlap@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltt-dev@shafik.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@redhat.com \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome