[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5df78e1d0812022130g7c5a004bnd729d0a8454f24ed@mail.gmail.com>
Date: Tue, 2 Dec 2008 21:30:05 -0800
From: Jiaying Zhang <jiayingz@...gle.com>
To: Steven Rostedt <srostedt@...hat.com>
Cc: linux-kernel@...r.kernel.org, Michael Rubin <mrubin@...gle.com>,
Martin Bligh <mbligh@...gle.com>,
Michael Davidson <md@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 3/3] kernel tracing prototype
On Tue, Dec 2, 2008 at 8:35 PM, Steven Rostedt <srostedt@...hat.com> wrote:
>
> On Tue, 2008-12-02 at 16:26 -0800, Jiaying Zhang wrote:
>> Refer to the previous email
>> "[RFC PATCH 0/3] A couple of feature requests to the unified trace
>> buffer".
>>
>> A kernel tracing prototype that uses the unified trace buffer to keep
>> the collected trace data.
>>
>
>> Index: linux-2.6.26.2/include/linux/ktrace.h
>> ===================================================================
>> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
>> +++ linux-2.6.26.2/include/linux/ktrace.h 2008-11-25
>> 11:32:37.000000000 -0800
>> @@ -0,0 +1,73 @@
>> +#ifndef _LINUX_KTRACE_H
>> +#define _LINUX_KTRACE_H
>> +
>> +#include <linux/types.h>
>> +
>> +struct kernel_trace;
>> +
>> +typedef void ktrace_probe_func(struct kernel_trace *, void *,
>> size_t);
>> +
>> +struct kernel_trace {
>> + const char *name;
>> + const char *format; /* format string describing variable
>> list */
>> + u32 enabled:1, event_id:31;
>> + ktrace_probe_func *func; /* probe function */
>> + struct list_head list; /* list head linked to the hash table
>> entry */
>> +} __attribute__((aligned(8)));
>> +
>> +extern int ktrace_enabled;
>> +
>> +/*
>> + * Make sure the alignment of the structure in the __ktrace section
>> will
>> + * not add unwanted padding between the beginning of the section and
>> the
>> + * structure. Force alignment to the same alignment as the section
>> start.
>> + */
>> +
>> +#define DEFINE_KTRACE_STRUCT(name) struct ktrace_struct_##name
>> +
>> +#ifdef CONFIG_KTRACE
>> +#define DO_TRACE(name, format, args...)
>> \
>> + do {
>> \
>> + static const char __kstrtab_##name[]
>> \
>> + __attribute__((section("__ktrace_strings")))
>> \
>> + = #name "\0" format;
>> \
>> + static struct kernel_trace __ktrace_##name
>> \
>> + __attribute__((section("__ktrace"), aligned(8))) =
>> \
>> + { __kstrtab_##name, &__kstrtab_##name[sizeof(#name)],
>> \
>> + 0, 0, NULL, LIST_HEAD_INIT(__ktrace_##name.list) };
>> \
>> + __ktrace_check_format(format, ## args);
>> \
>> + if (unlikely(ktrace_enabled) &&
>> \
>> + unlikely(__ktrace_##name.enabled))
>> { \
>> + struct ktrace_struct_##name karg = { args };
>> \
>> + (*__ktrace_##name.func)
>> \
>> + (&__ktrace_##name, &karg, sizeof(karg));
>> \
>> + }
>> \
>
> This looks like another form of markers/trace-points. Why not use them?
Yes. It borrows many ideas from the marker code. But we don't intend
to be as general as markers and lttng, which allows us to make many
simplifications and we think will give us performance benefits.
Jiaying
>
>> + } while (0)
>> +
>> +#else /* !CONFIG_KTRACE */
>> +#define DO_TRACE(name, format, args...)
>> +#endif
>> +
>
> -- Steve
>
>
>
--
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