Signed-off-by: Namhyung Kim
---
tools/lib/traceevent/parse-filter.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/tools/lib/traceevent/parse-filter.c
b/tools/lib/traceevent/parse-filter.c
index ab402fb2dcf7..d4b0bac80dc8 100644
--- a/tools/lib/traceevent/pa
On Wed, 11 Dec 2013 11:29:21 +0900
Namhyung Kim wrote:
> On Tue, 10 Dec 2013 20:55:26 -0500, Steven Rostedt wrote:
> > On Wed, 11 Dec 2013 09:40:35 +0900
> > Namhyung Kim wrote:
> >> And should we extend the error code to include the return value of
> >> pevent_filter_match() too? If not, it se
On Tue, 10 Dec 2013 20:55:26 -0500, Steven Rostedt wrote:
> On Wed, 11 Dec 2013 09:40:35 +0900
> Namhyung Kim wrote:
>> And should we extend the error code to include the return value of
>> pevent_filter_match() too? If not, it seems we need to pass another
>> argument to receive the actual error
On Wed, 11 Dec 2013 09:40:35 +0900
Namhyung Kim wrote:
> >>> Perhaps call it
> >>>
> >>> pevent->filter_error_buffer
> >>>
> >>> ?
> >
> > Hmm.. thinking about it twice, if it's only for filter functions
> > wouldn't it be better moving it to event_filter rather than pevent?
> >
> > filter
On Tue, 10 Dec 2013 14:30:18 +0900, Namhyung Kim wrote:
> On Tue, 10 Dec 2013 14:01:44 +0900, Namhyung Kim wrote:
>> On Mon, 9 Dec 2013 21:14:10 -0500, Steven Rostedt wrote:
>>> On Tue, 10 Dec 2013 11:03:44 +0900
>>> Namhyung Kim wrote:
>>>
What about returning error code rather than string?
On Tue, 10 Dec 2013 14:01:44 +0900, Namhyung Kim wrote:
> On Mon, 9 Dec 2013 21:14:10 -0500, Steven Rostedt wrote:
>> On Tue, 10 Dec 2013 11:03:44 +0900
>> Namhyung Kim wrote:
>>
>>> What about returning error code rather than string? This way we won't
>>> worry about the allocation of the error
On Mon, 9 Dec 2013 21:14:10 -0500, Steven Rostedt wrote:
> On Tue, 10 Dec 2013 11:03:44 +0900
> Namhyung Kim wrote:
>
>> What about returning error code rather than string? This way we won't
>> worry about the allocation of the error string itself.
>>
>> But the downside of it is loosing a posit
On Tue, 10 Dec 2013 11:03:44 +0900
Namhyung Kim wrote:
> What about returning error code rather than string? This way we won't
> worry about the allocation of the error string itself.
>
> But the downside of it is loosing a positional info of the error.
> Hmm.. what about using a static buffer
On Mon, 9 Dec 2013 14:23:50 -0500, Steven Rostedt wrote:
> On Mon, 9 Dec 2013 16:14:39 -0300
> Arnaldo Carvalho de Melo wrote:
>
>> Em Mon, Dec 09, 2013 at 02:03:42PM -0500, Steven Rostedt escreveu:
>> > On Mon, 9 Dec 2013 15:30:09 -0300
>> > Arnaldo Carvalho de Melo wrote:
>> >
>> >
>> > > > +
On Mon, 9 Dec 2013 16:14:39 -0300
Arnaldo Carvalho de Melo wrote:
> Em Mon, Dec 09, 2013 at 02:03:42PM -0500, Steven Rostedt escreveu:
> > On Mon, 9 Dec 2013 15:30:09 -0300
> > Arnaldo Carvalho de Melo wrote:
> >
> >
> > > > + error = malloc(MAX_ERR_STR_SIZE);
> > > > +
Em Mon, Dec 09, 2013 at 02:03:42PM -0500, Steven Rostedt escreveu:
> On Mon, 9 Dec 2013 15:30:09 -0300
> Arnaldo Carvalho de Melo wrote:
>
>
> > > + error = malloc(MAX_ERR_STR_SIZE);
> > > + if (error == NULL) {
> > > + /* no memory */
> > > + *err
On Mon, 9 Dec 2013 15:30:09 -0300
Arnaldo Carvalho de Melo wrote:
> > + error = malloc(MAX_ERR_STR_SIZE);
> > + if (error == NULL) {
> > + /* no memory */
> > + *error_str = "failed to allocate memory";
> > + return;
>
>
Em Mon, Dec 09, 2013 at 02:33:58PM +0900, Namhyung Kim escreveu:
> Signed-off-by: Namhyung Kim
> ---
> tools/lib/traceevent/parse-filter.c | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/tools/lib/traceevent/parse-filter.c
> b/tools/lib/traceevent/parse
Signed-off-by: Namhyung Kim
---
tools/lib/traceevent/parse-filter.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/tools/lib/traceevent/parse-filter.c
b/tools/lib/traceevent/parse-filter.c
index 2500e75583fc..0fc905c230ad 100644
--- a/tools/lib/traceevent/pa
14 matches
Mail list logo
