Date: Thu, 23 Jul 2020 19:44:21 -0400 From: Alexander Motin <mav@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r363188 - in head: lib/libpmc sys/dev/hwpmc Message-ID: <e74fefad-64bf-97bd-d0b4-8f1ac0466a30@FreeBSD.org> In-Reply-To: <70e7319b-93d6-a9d2-cf70-73a6a26616a5@FreeBSD.org> References: <202007141811.06EIB6b3008168@repo.freebsd.org> <70e7319b-93d6-a9d2-cf70-73a6a26616a5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e74fefad-64bf-97bd-d0b4-8f1ac0466a30>