Re: CVS commit: src/usr.bin/make
On Sun, Oct 25, 2020 at 05:37:36PM +, Simon J. Gerraty wrote: > Modified Files: > src/usr.bin/make: main.c > src/usr.bin/make/unit-tests: varmod-match-escape.exp > > Log Message: > Skip reading .MAKE.DEPENDFILE if set to > "/dev/null" or anything starting with "no". > > Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223564 I object to this, particularly the "no" part but also making /dev/null magic. This is an unnecessary workaround for a bug in freebsd's build system. If there's going to be a change, it should be removing the :T from the generated reference; there is no reason to remove the directory name from a user-supplied .MAKE.DEPENDFILE, and the default doesn't have a directory part. That would also remove the problem freebsd's seeing, and would be, y'know, actually correct. (also the application of :T is undocumented as well as wrong) kept for reference: > To generate a diff of this commit: > cvs rdiff -u -r1.388 -r1.389 src/usr.bin/make/main.c > cvs rdiff -u -r1.1 -r1.2 src/usr.bin/make/unit-tests/varmod-match-escape.exp -- David A. Holland dholl...@netbsd.org
re: CVS commit: src
"Nia Alarie" writes: > Module Name: src > Committed By: nia > Date: Sun Oct 25 16:39:00 UTC 2020 > > Modified Files: > src/share/man/man4: acpicpu.4 > src/share/man/man4/man4.x86: est.4 powernow.4 > src/sys/arch/evbmips/loongson: loongson_clock.c > src/sys/arch/macppc/dev: obio.c > src/sys/arch/x86/acpi: acpi_cpu_md.c > src/sys/arch/x86/x86: est.c powernow.c > > Log Message: > Normalize some machine dependent CPU frequenct sysctl variables. > > This moves machdep.*.frequency.* to machdep.cpu.frequency.*. > > This was proposed on tech-kern some time ago. The intention is to allow > third-party tools such as estd and conky to more easily and reliably > fetch or modify the current CPU frequency without iterating through > various machine-dependent variables to check their presence. sorry, i must have missed your tech-kern post. 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 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. .mrg. (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.)
