Re: CVS commit: src

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

On Tue, 2020-10-27 at 19:54 +0000, nia wrote:
> 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.

Yeah, that's my understanding. (I'm guessing Youri only had Intel
hardware to test with, which was also true for me until recently.)

> i thought kernel versions were specifically about module
> compatibility.

That may be the case, that was a question for any kernel developers at
large. :)

Dave