linux-kernel - Re: [PATCH 3/3] perf inject: Handle output file via perf_data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Nov 2013 11:03:24 +0100
From:	Jiri Olsa <jolsa@...hat.com>
To:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Mike Galbraith <efault@....de>,
	Stephane Eranian <eranian@...gle.com>,
	David Ahern <dsahern@...il.com>,
	Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCH 3/3] perf inject: Handle output file via perf_data_file
 object

On Mon, Nov 25, 2013 at 04:40:32PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 22, 2013 at 03:24:28PM +0100, Jiri Olsa escreveu:
> > Using the perf_data_file object to handle output

SNIP

> > +	if (!perf_data_file__is_pipe(&inject->output))
> >  		return 0;
> >  
> >  	return perf_event__repipe_synth(tool, event);
> > @@ -351,10 +343,12 @@ static int __cmd_inject(struct perf_inject *inject)
> >  {
> >  	struct perf_session *session;
> >  	int ret = -EINVAL;
> > -	struct perf_data_file file = {
> > +	struct perf_data_file file_in = {
> 
> Why don't leave it as 'file', and on a follow up patch _then_ rename it
> to file_in? This way patch review gets easier, i.e. try avoiding doing
> multiple things per patch.

the input file needed to be renamed, because new 'output' file was added

> 
> >  		.path = inject->input_name,
> >  		.mode = PERF_DATA_MODE_READ,
> >  	};
> > +	struct perf_data_file *file_out = &inject->output;
> > +	int out_fd = perf_data_file__fd(file_out);
> >  
> >  	signal(SIGINT, sig_handler);
> >  
> > @@ -365,7 +359,7 @@ static int __cmd_inject(struct perf_inject *inject)
> >  		inject->tool.tracing_data = perf_event__repipe_tracing_data;
> >  	}
> >  
> > -	session = perf_session__new(&file, true, &inject->tool);
> > +	session = perf_session__new(&file_in, true, &inject->tool);
> 
> This hunk, for example, wouldn't be here, the this patch would be
> shorter, easier to review.
> 
> >  	if (session == NULL)
> >  		return -ENOMEM;
> >  
> > @@ -391,14 +385,15 @@ static int __cmd_inject(struct perf_inject *inject)
> >  		}
> >  	}
> >  
> > -	if (!inject->pipe_output)
> > -		lseek(inject->output, session->header.data_offset, SEEK_SET);
> > +	if (!perf_data_file__is_pipe(file_out))
> > +		lseek(out_fd, session->header.data_offset, SEEK_SET);
> 
> Couldn't this be left as:
> 
> -	if (!inject->pipe_output)
> -		lseek(inject->output, session->header.data_offset, SEEK_SET);
> +	if (!perf_data_file__is_pipe(file_out))
> +		lseek(inject->output->fd, session->header.data_offset, SEEK_SET);
> 
> I.e. why wrap access to the fd like that?

well, inject->output->fd is used on 2 places within the function,
so it seems logical to put it into variable and use it like that

> 
> >  
> >  	ret = perf_session__process_events(session, &inject->tool);
> >  
> > -	if (!inject->pipe_output) {
> > +	if (!perf_data_file__is_pipe(file_out)) {
> >  		session->header.data_size = inject->bytes_written;
> > -		perf_session__write_header(session, session->evlist, inject->output, true);
> > +		perf_session__write_header(session, session->evlist, out_fd,
> > +					   true);
> 
> Why a line for 'true' all by itself?

line was crossing 80 chars limit

> 
> >  	}
> >  
> >  	perf_session__delete(session);
> > @@ -427,14 +422,17 @@ int cmd_inject(int argc, const char **argv, const char *prefix __maybe_unused)
> >  		},
> >  		.input_name  = "-",
> >  		.samples = LIST_HEAD_INIT(inject.samples),
> > +		.output = {
> > +			.path = "-",
> > +			.mode = PERF_DATA_MODE_WRITE,
> > +		},
> >  	};
> > -	const char *output_name = "-";
> >  	const struct option options[] = {
> >  		OPT_BOOLEAN('b', "build-ids", &inject.build_ids,
> >  			    "Inject build-ids into the output stream"),
> >  		OPT_STRING('i', "input", &inject.input_name, "file",
> >  			   "input file name"),
> > -		OPT_STRING('o', "output", &output_name, "file",
> > +		OPT_STRING('o', "output", &inject.output.path, "file",
> 
> see, here you directly access a perf_data_file member instead of having
> another wrapper :-)

yes

I dont have strong opinions about wrappers, sometimes it seems
appropriate, sometimes it does not.. tell me the guidance here
and I'll kick the patch to fit ;-)

thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/