Messages in this thread | | | Subject | Re: [PATCH 2/2] tracing/filters: remove error messages | From | Tom Zanussi <> | Date | Thu, 18 Jun 2009 01:10:52 -0500 |
| |
On Thu, 2009-06-18 at 09:17 +0800, Li Zefan wrote: > Frederic Weisbecker wrote: > > On Wed, Jun 17, 2009 at 04:47:15PM +0800, Li Zefan wrote: > >> Now we restore original filter is the new one can't be applied, > >> and no long show error messages, so we can remove them totally. > > > > Why? > > These messages are very powerful to point a user to its mistakes > > in filters syntaxes or semantics. > > > > I really think we are removing a very useful feature in this patch. > > > > I think it's better done by providing a user-space program/script. > > So what's the criterion to decide what should be in kernel and > what should be in user-space? >
I thought there wasn't supposed to be any userspace for non-binary tracing. If there is, then yeah, you can get rid of the error messages in the kernel because your userspace program can arrange to never submit an erroneous filter.
> btw, this feature is not full-fledged, that it can't point to the > exact position where error occured, and the implementation will add > complexity and I'm sure it's worthy or not. >
It could, it just doesn't yet. But even without exact position information, the messages should still be useful in most cases.
Tom
> > May be we can keep the previous filter in case of new filter string > > inserting failure, though if the user wanted to insert a new one, there > > are few chances that the previous one is still relevant for him. > > I don't know. > > > >> Another reason is, I don't think it's good to show error messages > >> when reading a control file. > > > > So, why not create a filter_error file in this case? One for each > > event and subsys that would print the last error? > > > > Yeah, if we do want to keep this feature in the kernel.
| |