[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120207090622.GC15359@elte.hu>
Date: Tue, 7 Feb 2012 10:06:23 +0100
From: Ingo Molnar <mingo@...e.hu>
To: David Ahern <dsahern@...il.com>
Cc: acme@...stprotocols.net, linux-kernel@...r.kernel.org,
peterz@...radead.org, fweisbec@...il.com, paulus@...ba.org,
tglx@...utronix.de
Subject: Re: [PATCH] perf-record: no build id option fails
* David Ahern <dsahern@...il.com> wrote:
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -504,9 +504,9 @@ static int __cmd_record(struct perf_record *rec, int argc, const char **argv)
> return err;
> }
>
> - if (!!rec->no_buildid
> + if (!rec->no_buildid
> && !perf_header__has_feat(&session->header, HEADER_BUILD_ID)) {
> - pr_err("Couldn't generating buildids. "
> + pr_err("Couldn't generate buildids. "
> "Use --no-buildid to profile anyway.\n");
After this fix it might make sense to do a s/no_buildid/build_id
across the source and negate all the conditions. Generally it's
cleaner to have no negation in structure field names, it avoids
such double and triple negation problems.
The feature bit did it correctly: it has HEADER_BUILD_ID which
signals the presence of build-ids.
( Btw., in error messages it might make sense to do a
subsystem-wide s/buildid/build-id rename as well, to make it
all easier to read - when I read 'buildid' I often keep
wondering who that Buil guy is and what he did. )
Thanks,
Ingo
--
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/
Powered by blists - more mailing lists