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.

I spoke too soon. The quirk mechanism won't work here without other changes, as /etc/rc.conf is truncated after the quirk is called.

I added the following comment to the bug:

Moving the #endif might be worth mentioning in the description too; only TCP_NODELAY should be visible without __BSD_VISIBLE

Thanks for moving the #endif!

There is another namespace issue in tcp.h. There have been several additions near the end of the file, after the #endif at line 458. The #endif closes the #ifdef _BSD_VISIBLE at line 181. The #endif should be moved to line 544, just before the closing #endif, as the additions are not in POSIX, and the #endif should be commented as /* _BSD_VISIBLE */ so people are less likely to add things after it. If you don't want to combine the namespace fixes, I can do it later.

Most of netinet/tcp.h is already inside #ifdef __BSD_VISIBLE, so it would be "legal" to use tcp_[gs]et_flags. It would be better to avoid intruding into the BSD namespace, though, using __tcp_[gs]et_flags for user space, and providing aliases for the kernel. I can imagine network tools using these names.

Looks good to me.

Oh, the title has a typo in the man page name.

The change seems reasonable to me. I marked a pre-existing nit that is probably worth fixing while in the area.

I think this is a step in the right direction (having the compression specified in the config file), but I think it needs better integration with the existing flags. For example, there could be a new flag selecting the default as specified with <compress>, replacing J in the default config file lines.

Looks plausible to me, but I'll let someone more familiar with the code approve.

Any questions or comments on this review?