In D44453#1018221, @koinec_yahoo.co.jp wrote:

In D44453#1017213, @karels wrote:

Is this project derived from Intel's code (see https://github.com/intel/intel_hfi)? It was originally GPL, but is now dual-licensed.

I understand that this github code has no origin.
I based this driver on FreeBSD's coretemp driver.

Since this is a serious topic related to licensing, I will explain it in a little more detail.
This github is the source code of the driver for Linux kernel, and I learned it.
However, the PowerManagement-related mechanisms are different between the Linux kernel and FreeBSD. In the Linux kernel, this is added to the existing thermal throtlling code, but FreeBSD does not have this mechanism.
Therefore, it is not possible to create the coredirector driver using the source code from this github.
As proof of this, for example, I needed to add the Local APIC's thermal interupt handler as a patch in Part 2.
Also, the table reference processing of Intel HFI/TD is simple, just referencing the table when an thermal interrupt occurs. I believe that if it were created based on the Intel SDM article, the process flow would be similar.

Is this project derived from Intel's code (see https://github.com/intel/intel_hfi)? It was originally GPL, but is now dual-licensed.

In D44453#1014665, @koinec_yahoo.co.jp wrote:

I'm sorry.
I tried uploading a full-context patch file from "Update Diff" in the upper right menu, but when I download it afterwards, only the modified parts are shown.
Since I don't know how to use this site, I will attach the full context file here.
If I'm wrong, please let me know how to upload it.

{F79832604}

fwiw, I've been experimenting with sched_ule changes for hybrid cores, although I have nothing worth committing yet. I'll be interested to see the rest of this.

I'm going to push this now, but please send me any additional comments.

Remove rollback warning, it is incorrect for 13.3. Add gve,
re-adding virtualization section.

Does -Wswitch require a default if all values of an enum are explicitly included? I don't know if that is common though.

Add vnode/vfs sysctl section from 14.0.

Various updates from out-of-band correspondence with involved parties;
update zlib revision; a few additions including clang.

John, I included you specifically for the last section on 32-bit systems, but I think you have at least one other item in here.

Has anyone else from docs looked at this? Anyone willing to approve?

Remove PowerPC updating note (probably no longer applies);
correct sentence about "new in this release unless marked MERGED";
remove section about i386 CPUTYPE.

Is the following summary accurate: This change is not required for all systems, but doesn't hurt; it makes it easier for some configurations. If that's true, then I don't have a problem with it.

Seems like the same list as -CURRENT, right? That should be correct.

Looks right to me.

Anyone from manpages want to approve this?

Looks good, I can approve for releng; someone from docs should approve, though, and commit if necessary.

In D43466#990869, @olce wrote:

In D43466#990866, @dvl wrote:

I think you're saying why have a command-line switch when we have the in-conf-file option?

I was just trying to guess the reasoning for the removal of this command-line option, by stating one possible inference, since I anticipate that the use of -c is infrequent and it's always possible for the administrator to change the configuration file (well, I also can see situations where these are not equivalent...). Personally, I don't have a need to remove it, and at the same time I'll likely never use it, in that sense I'm neutral.

Use local variables to factor out parts of long expression, simplify

I tried formatting the check as a separate function, and that doesn't help much. The main part of the expression (computing the host part) still doesn't fit on one line. I think I'll leave it as it is.

Any comments on this, including the plan to MFC? I didn't reply to Ed's comment on the bug about possibly erroring on 15, and restoring the workaround on 13 and 14,. But I think it will have been long enough since this "worked" that people will have gotten used to the new behavior unless they stick with 12.4 until 13.3 is out.

There is an alternative approach in https://reviews.freebsd.org/D43141. The main difference is that it splits RPI4 into a separate image, leaving RPI for RPi 3 etc. I don't think that is necessary, as noted in that review. The other difference is in using the quirks mechanism, which would require modification to be effective in this case.

I put my change in review https://reviews.freebsd.org/D43296. Comments welcome.