On 15/04/2021 17:41, Leo Yan wrote:
> Hi James,
>
> On Thu, Apr 15, 2021 at 05:13:36PM +0300, James Clark wrote:
>> On 12/04/2021 12:10, Leo Yan wrote:
>>> The enum value 'ARM_SPE_PER_CPU_MMAPS' is never used so remove it.
>>
>> Hi Leo,
>>
>> I think this causes an error when attempting to open a newly recorded file
>> with an old version of perf. The value ARM_SPE_AUXTRACE_PRIV_MAX is used
>> here:
>>
>> size_t min_sz = sizeof(u64) * ARM_SPE_AUXTRACE_PRIV_MAX;
>> struct perf_record_time_conv *tc = &session->time_conv;
>> struct arm_spe *spe;
>> int err;
>>
>> if (auxtrace_info->header.size < sizeof(struct
>> perf_record_auxtrace_info) +
>> min_sz)
>> return -EINVAL;
>>
>> And removing ARM_SPE_PER_CPU_MMAPS changes the value of
>> ARM_SPE_AUXTRACE_PRIV_MAX.
>>
>> At least I think that's what's causing the problem. I get this error:
>>
>> ./perf report -i per-thread-spe-time.data
>> 0x1c0 [0x18]: failed to process type: 70 [Invalid argument]
>> Error:
>> failed to process sample
>> # To display the perf.data header info, please use
>> --header/--header-only options.
>> #
>
> Yes, when working on this patch I had concern as well.
>
> I carefully thought that the perf tool should be backwards-compatible,
> but there have no requirement for forwards-compatibility. This is the
> main reason why I kept this patch.
>
> If you or anyone could confirm the forwards-compatibility is required,
> it's quite fine for me to drop this patch.
>
Personally, I can easily imagine sending a file to someone to open with an
older version and it causing
friction where it could be easily avoided. And it even made testing a bit more
difficult because
I wanted to compare opening the same file with the patched and un-patched
version. But if there
is no hard requirement I can't really put too much pressure to not remove it.
> Thanks a lot for the reviewing and testing!
> Leo
>
