All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Tom Zanussi <tzanussi@gmail.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] tracing/filters: disallow newline as delimeter
Date: Wed, 22 Apr 2009 10:09:28 +0200	[thread overview]
Message-ID: <20090422080928.GA8562@elte.hu> (raw)
In-Reply-To: <1240377698.6711.61.camel@tropicana>


* Tom Zanussi <tzanussi@gmail.com> wrote:

> On Tue, 2009-04-21 at 12:16 +0200, Ingo Molnar wrote:
> > * Li Zefan <lizf@cn.fujitsu.com> wrote:
> > 
> > > Ingo Molnar wrote:
> > > > * Li Zefan <lizf@cn.fujitsu.com> wrote:
> > > > 
> > > >> Ingo Molnar wrote:
> > > >>> * Li Zefan <lizf@cn.fujitsu.com> wrote:
> > > >>>
> > > >>>> I guess because user input is often ended with '\n' (like "echo 
> > > >>>> xxx"), thus '\n' is used as a delimeter besides ' ', but we can 
> > > >>>> just strip tailing spaces.
> > > >>> Hm, how about:
> > > >>>
> > > >>> ( echo 'x'
> > > >>>   echo '|| y' ) > filter
> > > >>>
> > > >>> type of scripts? Shouldnt the parser be permissive in general?
> > > >>>
> > > >> This patch doesn't forbid this usage: ;)
> > > >>
> > > >> ( echo 'parent_comm == a'
> > > >>   echo '|| parent_comm == b' ) > filter
> > > >>
> > > >> This patch does forbid this usage:
> > > >>
> > > >> ( echo 'parent_comm'
> > > >>   echo '=='
> > > >>   echo 'a' ) > filter
> > > > 
> > > > Same argument though, no?
> > > > 
> > > 
> > > Then I have no strong opinion on this. I'm fine to drop this patch.
> > 
> > I've applied the other two - no strong opinion either about this 
> > patch. Tom, what do you think? (there's also some new parser in the 
> > works i suspect)
> 
> I think it works ok as it is, so dropping this patch would be fine 
> with me.
> 
> I am working on a new parser; I'd hoped to have it finished by 
> now, but I seem to be continually distracted lately. :-( At this 
> point I have a parser that basically works; the main thing it 
> still needs and what I'm working on now is a way to allow it to be 
> easily extended to support special-case handling for special types 
> e.g. if a predicate field refers to something that's a dev_t, the 
> user should be able to specify 'device == /dev/sda' or 'device == 
> sda' or 'device == (8,1)' or 'device == 8:1', so it should be 
> relatively easy to add that kind of support to the parser when 
> there's a need for it.
> 
> Once that's done, I'll hook it all up and post it as soon as I 
> can, at the end of the week hopefully...

Nice! :-)

If your current lineup works you might want to post that straight 
away even without the type extensions, if you think there's value in 
testing/reviewing those bits independently. It generally works 
better to have gradual patches. (we can find bugs sooner, review is 
easier, etc.)

	Ingo

  reply	other threads:[~2009-04-22  8:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-21  9:11 [PATCH 1/3] tracing/filters: don't remove old filters when failed to write subsys->filter Li Zefan
2009-04-21  9:12 ` [PATCH 2/3] tracing/filters: allow user-input to be integer-like string Li Zefan
2009-04-21 10:08   ` [tip:tracing/core] " tip-bot for Li Zefan
2009-04-21  9:12 ` [PATCH 3/3] tracing/filters: disallow newline as delimeter Li Zefan
2009-04-21  9:57   ` Ingo Molnar
2009-04-21 10:06     ` Li Zefan
2009-04-21 10:07       ` Ingo Molnar
2009-04-21 10:14         ` Li Zefan
2009-04-21 10:16           ` Ingo Molnar
2009-04-22  5:21             ` Tom Zanussi
2009-04-22  8:09               ` Ingo Molnar [this message]
2009-04-23  5:18                 ` Tom Zanussi
2009-04-21 10:08 ` [tip:tracing/core] tracing/filters: don't remove old filters when failed to write subsys->filter tip-bot for Li Zefan

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=20090422080928.GA8562@elte.hu \
    --to=mingo@elte.hu \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=rostedt@goodmis.org \
    --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.