From: Masami Hiramatsu <mhiramat@kernel.org>
To: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
"linux-perf-use." <linux-perf-users@vger.kernel.org>,
Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Subject: Re: perf buildid-cache -p <path> question
Date: Thu, 26 Oct 2017 02:04:08 +0900 [thread overview]
Message-ID: <20171026020408.053d2985bdd1e4fef824fbcb@kernel.org> (raw)
In-Reply-To: <140bd721-4929-22ee-ce77-b7fe575a470c@linux.vnet.ibm.com>
On Tue, 24 Oct 2017 09:56:02 +0200
Thomas-Mich Richter <tmricht@linux.vnet.ibm.com> wrote:
> On 10/20/2017 06:20 PM, Arnaldo Carvalho de Melo wrote:
> > Em Sat, Oct 21, 2017 at 01:12:59AM +0900, Masami Hiramatsu escreveu:
> >> On Mon, 16 Oct 2017 11:12:22 -0300
> >> Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >>
> >>
> >> For example, you have a /usr/bin/tar (this is old tar) and its buildid-cache
> >> in cache directory by perf buildid-cache -a /usr/bin/tar.
> >> And at some point, you will update the /usr/bin/tar (this is new tar).
> >> This new tar binary is not same as old one, so if you also do
> >> perf buildid-cache -a /usr/bin/tar, it creates another version of buildid
> >> cache in cache directory.
> >>
> >> At this moment,
> >> $ perf buildid-cache -r /usr/bin/tar
> >> will remove only new tar's buildid cache, but old one remains.
> >>
> >> On the other hand,
> >> $ perf buildid-cache -p /usr/bin/tar
> >> will remove all the caches related to /usr/bin/tar from buildid cache.
> >>
> >> And since the -p is supposed to be used for cleanup, it doesn't return
> >> error even if there is no buildid cache remaining.
> >>
> >>
> >> Should it work for a directory instead of a file too?
> >> I need to investigate it too.
> >
> > Isn't that implemented by I patch by Thomas?
> >
> > - Arnaldo
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> Ok, I have understood the behavior of commands
> perf buildid-cache -a
> and
> perf buildid-cache -r.
>
> Same with command perf buildid-cache -p /usr/bin/tar.
> It works correctly if you specify a file name and not a directory as I did
> in my previous append.
>
> I was mislead by the man page which says
> "file list" for option -a
> "file(s) to remove" for option -r
> "path(s) to remove (remove old caches too)' for option -p
>
> I just find it confusing to explicitly mention files for
> option -a and -r whereas option -p mentions path.
>
> We can drop my patch but I would like to clarify the man page
> to explicitly mention "file(s)" or "file list" instead of path for option -p.
>
> What do you think?
Indeed. Originally the "file" means existing file but "path" means the path in the
cache, which can be already removed. However, that can mislead users.
So I agree that is unified to "file list".
Thank you,
>
> --
> Thomas Richter, Dept 3303, IBM LTC Boeblingen Germany
> --
> Vorsitzende des Aufsichtsrats: Martina Koederitz
> Geschäftsführung: Dirk Wittkopp
> Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
>
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2017-10-25 17:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 12:24 perf buildid-cache -p <path> question Thomas-Mich Richter
2017-10-16 13:45 ` Thomas-Mich Richter
2017-10-16 14:12 ` Arnaldo Carvalho de Melo
2017-10-20 16:12 ` Masami Hiramatsu
2017-10-20 16:20 ` Arnaldo Carvalho de Melo
2017-10-24 7:56 ` Thomas-Mich Richter
2017-10-25 17:04 ` Masami Hiramatsu [this message]
2017-10-26 7:05 ` Thomas-Mich Richter
2017-10-21 15:17 ` Masami Hiramatsu
2017-10-24 6:50 ` Thomas-Mich Richter
2017-10-25 16:57 ` Masami Hiramatsu
2017-10-26 7:07 ` Thomas-Mich Richter
2017-10-26 14:41 ` Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171026020408.053d2985bdd1e4fef824fbcb@kernel.org \
--to=mhiramat@kernel.org \
--cc=acme@kernel.org \
--cc=brueckner@linux.vnet.ibm.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=tmricht@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.