From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753383AbbBEV3j (ORCPT ); Thu, 5 Feb 2015 16:29:39 -0500 Received: from smtprelay0150.hostedemail.com ([216.40.44.150]:55191 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753258AbbBEV3g (ORCPT ); Thu, 5 Feb 2015 16:29:36 -0500 X-Session-Marker: 6E657665747340676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::,RULES_HIT:41:355:379:541:599:960:973:982:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:2393:2553:2559:2562:2895:3138:3139:3140:3141:3142:3354:3622:3865:3866:3867:3868:3870:3871:3872:3873:4321:4605:5007:6261:7576:7875:7903:10004:10400:10471:10848:10967:11026:11232:11658:11914:12043:12114:12296:12517:12519:12555:12740:13255:21080,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0 X-HE-Tag: need96_70ba4753a574c X-Filterd-Recvd-Size: 3190 Date: Thu, 5 Feb 2015 16:29:33 -0500 From: Steven Rostedt To: Al Viro Cc: linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 5/7] trace: make filter_parse_regex() provide the length of substring to compare with Message-ID: <20150205162933.4fad48f6@gandalf.local.home> In-Reply-To: <1423166200-1800-5-git-send-email-viro@ZenIV.linux.org.uk> References: <20150205194914.GR29656@ZenIV.linux.org.uk> <1423166200-1800-5-git-send-email-viro@ZenIV.linux.org.uk> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 5 Feb 2015 19:56:38 +0000 Al Viro wrote: > From: Al Viro > > ... by passing len by address and using it to report the length of > substring in question. You certainly are very verbose in your change logs. What exactly is the purpose of this patch? Clean up? Optimization? I can't really tell. Seems like you are just moving the strlen() from outside the function into it. > --- a/kernel/trace/trace.h > +++ b/kernel/trace/trace.h > @@ -1051,7 +1051,7 @@ struct filter_pred { > }; > > extern enum regex_type > -filter_parse_regex(char *buff, int len, char **search, int *not); > +filter_parse_regex(char *buff, int *len, char **search, int *not); > extern void print_event_filter(struct ftrace_event_file *file, > struct trace_seq *s); > extern int apply_event_filter(struct ftrace_event_file *file, > diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c > index 6c4a96b..6a659e1 100644 > --- a/kernel/trace/trace_events_filter.c > +++ b/kernel/trace/trace_events_filter.c > @@ -321,7 +321,7 @@ static int regex_match_end(char *str, struct regex *r, int len) > * not returns 1 if buff started with a '!' > * 0 otherwise. > */ @len above needs to be updated for kernel doc. The description should also note what *len gets set to at the end. > -enum regex_type filter_parse_regex(char *buff, int len, char **search, int *not) > +enum regex_type filter_parse_regex(char *buff, int *len, char **search, int *not) > { > int type = MATCH_FULL; > int i; > @@ -329,13 +329,13 @@ enum regex_type filter_parse_regex(char *buff, int len, char **search, int *not) > if (buff[0] == '!') { > *not = 1; > buff++; > - len--; > + (*len)--; > } else > *not = 0; > > *search = buff; > > - for (i = 0; i < len; i++) { > + for (i = 0; i < *len; i++) { > if (buff[i] == '*') { > if (!i) { > *search = buff + 1; > @@ -350,6 +350,7 @@ enum regex_type filter_parse_regex(char *buff, int len, char **search, int *not) > } > } > } > + *len = strlen(*search); We could optimize this even further: *len = &buff[i] - *search; -- Steve > > return type; > }