On 31 March 2017 at 04:24, Kim Phillips kim.phillips@arm.com wrote:
On Wed, 29 Mar 2017 11:43:56 -0600 Mathieu Poirier mathieu.poirier@linaro.org wrote:
Adding information on kernel versioning at the top of the file and replacing all instances of numerical kernel versions with a generic notation.
Signed-off-by: Mathieu Poirier mathieu.poirier@linaro.org
HOWTO.md | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-)
diff --git a/HOWTO.md b/HOWTO.md index 2a6be3db0164..71b228c8f5f7 100644 --- a/HOWTO.md +++ b/HOWTO.md @@ -7,16 +7,18 @@ This HOWTO explains how to use the perf cmd line tools and the openCSD library to collect and extract program flow traces generated by the CoreSight IP blocks on a Linux system. The examples have been generated using an aarch64 Juno-r0 platform. All information is considered accurate and tested -using library version v0.5 and the latest perf branch `perf-opencsd-4.9` -on the [OpenCSD github repository][1]. +using library version v0.5 and the latest coresight/perf integration branch on +on the [OpenCSD github repository][1]. That branch is labelled +`perf-opencsd-($VERSION)`, where ($VERSION) carries the latest kernel version +number.
Wouldn't it be easier to just have a fixed-name 'perf-opencsd' branch contain always the 'latest' development code, even if it gets rebased? This is how the upstream acme 'perf/core' branch works. It should be obvious to users that older versions can always be referred to by their 'perf-opencsd-x.y' style names, just by those branches being present
That's a very good idea - I will start doing that for the 4.12 cycle that will start sometime around the beginning of May.
(assuming you want to keep them present for some reason?).
I keep the older branches around so that we can go back if something is not working properly. On the flip side it is probably time to start deleting the older ones.
Mathieu
Kim