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.