Re: CVS commit: src

["David H. Gutteridge" <david%gutteridge.ca@localhost>]

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