Re: CVS commit: src

[nia <nia%NetBSD.org@localhost>]

On Tue, Oct 27, 2020 at 03:14:29PM -0400, David H. Gutteridge wrote:
> 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
> 
>

i can have a look at mate-applets tomorrow, the current code looks
like it won't work with AMD CPUs on netbsd-9 and that should ideally
be fixed.

i thought kernel versions were specifically about module compatibility.