svn commit: r363188 - in head: lib/libpmc sys/dev/hwpmc

[Mateusz Guzik]

I don't think that's worth the effort. However, versioning would be
nice. Then tooling could nicely crap out immediately instead of giving
funny results (or no results).

On 7/24/20, Alexander Motin <mav at freebsd.org> wrote:
> On 23.07.2020 19:15, John Baldwin wrote:
>> On 7/14/20 11:11 AM, Alexander Motin wrote:
>>> Author: mav
>>> Date: Tue Jul 14 18:11:05 2020
>>> New Revision: 363188
>>> URL: https://svnweb.freebsd.org/changeset/base/363188
>>>
>>> Log:
>>>   Add stepping to the kern.hwpmc.cpuid string on x86.
>>>
>>>   It follows the equivalent Linux change to be able to differentiate
>>>   skylakex and cascadelakex, sharing the same model but not stepping.
>>>
>>>   This fixes skylakex handling broken by r363144.
>>
>> Unfortunately this breaks compatibility meaning you can't use an older
>> libpmc with a newer kernel module after this change.  Perhaps we don't
>> consider libpmc stable, but this was really annoying as I booted a test
>> kernel today on an older Haswell box whose world is from before this
>> change and pmc doesn't work at all.  (pmccontrol -L doesn't list any
>> valid counters as the older libpmc presumably chokes on the additional
>> suffix and doesn't match anything)
>
> Unfortunately so.  I've added other way compatibility, but can't change
> the past.  Do you think it is critical enough to add more compat shims,
> like extra sysctls?
>
> --
> Alexander Motin
>


-- 
Mateusz Guzik <mjguzik gmail.com>