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 <m...@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> _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"