From: Li Zefan <lizf@cn.fujitsu.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Tom Zanussi <tzanussi@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [RFC][PATCH 5/5] tracing/filters: Provide support for char * pointers
Date: Thu, 06 Aug 2009 11:50:07 +0800 [thread overview]
Message-ID: <4A7A52EF.503@cn.fujitsu.com> (raw)
In-Reply-To: <20090806015949.GB24609@nowhere>
>> How about add __field_type()? So we can define:
>>
>> __field_type(char *, str, FILTER_PTR_STR)
>>
>> the advantage is he who wrote the code really knows this field is safe
>> to be used in filtering as a string.
>>
>> I had some patches that does similar job. I can rewrite and post them.
>
> Ah good idea. That may even be useful for further typedef'ed types which
> filter process match existing supported types.
>
That's why I wrote those patches, to allow:
# dev is type dev_t
echo "dev == 8:0" > filter
# callsite is void *
echo "callsite == kfree_skb" > filter
> Just one neat however: __field_type looks too much ambiguous. __field() is
> already here to define a typed field. This seems confusing.
>
> Why not __field_ext() for "extended"? We may probably add more flags
> than FILTER_PTR_STR in the future to define options for filtering or even
> for larger scope.
>
Sure. You know I'm not good at naming. ;)
> I then wait for your patches to be posted and I'll integrate them in the
> current queue.
>
Will soon be ready.
prev parent reply other threads:[~2009-08-06 3:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-01 7:23 [RFC][GIT PULL] bkl ftrace events + filter regex support Frederic Weisbecker
2009-08-01 7:23 ` [RFC][PATCH 1/5] tracing/bkl: Add bkl ftrace events Frederic Weisbecker
2009-08-01 7:23 ` [RFC][PATCH 2/5] tracing/event: Cleanup the useless dentry variable Frederic Weisbecker
2009-08-01 7:23 ` [RFC][PATCH 3/5] tracing/filters: Cleanup useless headers Frederic Weisbecker
2009-08-03 5:19 ` Li Zefan
2009-08-05 22:30 ` Frederic Weisbecker
2009-08-01 7:23 ` [RFC][PATCH 4/5] tracing/filters: Provide basic regex support Frederic Weisbecker
2009-08-03 5:39 ` Li Zefan
2009-08-05 22:47 ` Frederic Weisbecker
2009-08-06 1:14 ` Li Zefan
2009-08-06 1:49 ` Frederic Weisbecker
2009-08-07 4:14 ` Tom Zanussi
2009-08-07 5:19 ` Frederic Weisbecker
2009-08-07 8:11 ` Peter Zijlstra
2009-08-01 7:23 ` [RFC][PATCH 5/5] tracing/filters: Provide support for char * pointers Frederic Weisbecker
2009-08-03 6:58 ` Li Zefan
2009-08-05 23:02 ` Frederic Weisbecker
2009-08-06 1:35 ` Li Zefan
2009-08-06 1:59 ` Frederic Weisbecker
2009-08-06 3:50 ` Li Zefan [this message]
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=4A7A52EF.503@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=fweisbec@gmail.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tzanussi@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.