On Tue, 27 Oct 2020 at 09:04:28 +0000, nia wrote: >On Tue, Oct 27, 2020 at 01:16:00PM +1100, matthew green wrote: >> this doesn't seem like the right design. we have cpus >> already that have multiple frequency domains, so this >> doesn't work with that setup, so attempt to use it as a >> general method for estd etc seems limited and thsu not >> the right method. >> >> eg, rk3399 systems have .cpu0 and .cpu4 domains for the >> 4 slow and 2 fast cores it has, and they have both >> separate controls as well as list of available freqs: >> >> machdep.cpufreq.cpu0.target = 1416 >> machdep.cpufreq.cpu0.current = 1416 >> machdep.cpufreq.cpu0.available = 1416 1200 1008 816 600 408 >> machdep.cpufreq.cpu4.target = 1800 >> machdep.cpufreq.cpu4.current = 1800 >> machdep.cpufreq.cpu4.available = 1800 1608 1416 1200 1008 816 600 408 >> > >yeah, i'm aware of this, my intent was really only to normalize >the variables that didn't have multi-cpu-domain support (since >those are already normalized as rk3399) > >do you think we should use the same variable and tie things to >under cpu0 when there isn't support for scaling independent CPUs? > >> additionally, if we are going to design a "good" API for >> this, it should publish things outside of "machdep". >> i'd go with hw.cpufreq probbaly. >> >> (i didn't look, but it sure would be annoying if the old >> nodes that have existed for over a decade were changed >> and any other 3rd party code or scrip tis now broken.) > >i actually picked this name because it was already in use and >thus already checked by estd. > >i agree it should go outside machdep, but i didn't want >to break existing code.
This has impacted youri@'s NetBSD frequency handling patches in x11/ mate-applets, which only make references using "machdep.est.frequency" at present. Since this change removes pre-existing sysctl nodes, shouldn't this merit a kernel version bump? It potentially breaks things in user- space. (I see from the mailing list archives that Mouse asked about the idea of retaining old names for compatibility.) (Now, the mate-applets situation could be improved by the new, generic means of exposing this information. martin@ had asked for non-x86 support in PR pkg/53975, one of the barriers being I imagine few people have the hardware to test with. I don't.) Dave