Re: [PATCH] perf tools: Provide backward compatibility withprevious perf.data version

[Frederic Weisbecker]

On Thu, Oct 08, 2009 at 10:07:29PM +0200, Frederic Weisbecker wrote:
> We have merged the trace.info file into perf.data by adding one section
> in the perf headers. This makes it incompatible with previous version:
> the new perf tools can't read the older perf.data.
> 
> To support the previous format, we check the headers size. If they
> have the same size than in the previous format, then ignore the trace
> info section that doesn't exist.
> 
> Signed-off-by: Frederic Weisbecker <fweisbec@xxxxxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
> Cc: Mike Galbraith <efault@xxxxxx>
> Cc: Paul Mackerras <paulus@xxxxxxxxx>
> ---
>  tools/perf/util/header.c |    8 +++++++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> index 212fade..9aae360 100644
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c
> @@ -287,10 +287,16 @@ struct perf_header *perf_header__read(int fd)
>  	do_read(fd, &f_header, sizeof(f_header));
>  
>  	if (f_header.magic	!= PERF_MAGIC		||
> -	    f_header.size	!= sizeof(f_header)	||



Few notes about this.
I can send a separate fix for .32 that would just consist in the above line,
or more likely I can replace it by:

	f_header.size < sizeof(f_header)     ||

and then we'll get a minimal forward compatibility from the older
tools (can be Cc'ed to stable for .31).

Another thing. We may feel the need to add yet another sections
in the future.

So just a suggestion: we could turn this trace_info section into a
more generic one in which we could add as much subsections as we want
in the future while always ensuring backward compatibility. That could
be managed through a versioning of this generic section.

Of course I don't wish too much format modifications
will happen in the future, because it means difficults interaction
between several perf tools versions.

That said, it could still happen if important new needs arise and
I guess we don't want to be blocked by the header size.

The other solution is to continue like I did in this patch: guess the
version of this file format against its size.

Thanks.

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