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?

Remove useless printf; fix typo in man page

Does this need rebasing again (-u was moved)? Otherwise looks good.

Double-checking the places where this gets used, I don't think context is important. I agree with the long MFC just in case.

LGTM too

Add sysctls to man page; rename mem_percent sysctl to memory_percent
to be parallel to memory_reserve.

I spent a little time testing ZFS yesterday out of curiosity. With increasing memory pressure, it looked like it downsized the ARC somewhat. As I added files to tmpfs, the free space didn't go down as much as the content added. But ZFS needs management in most cases; the default seems to assume that the box is a ZFS file server (even for local use), and that ZFS owns most of memory. I also limit the ARC manually. But with any substantial competition for memory, the sysadmin really needs to set limits and/or tune. tmpfs can limit use by setting the size explicitly.

In D43011#981565, @rgrimes wrote:

This certainly makes things better, but I wonder how it gets along with the other memory pigs, ZFS and bhyve?

Address review comments.

I wouldn't object to this. Scripts that previously used no options to diff could just use ${daily_diff_flags}.

Re-reading the man page addition, it is probably overly specific even when the scripts are brought into the picture; it makes it sounds like it is every diff invoked by a daily script. Something more accurate would be good, e.g. referring to "some scripts" or something like that.

If we want to MFC anything soon, I prefer this approach. I wouldn't say that the other part should never be MFCed, but I wouldn't do it anytime soon. The daily output may not be easily machine-parseable, but that doesn't mean there aren't people doing it. Going from plain diff to -U 0 shouldn't lose information (whereas -u to -U 0 can, if context means anything). If this change is separate, any of the scripts in the other set could be merged individually, or new scripts could use daily_diff_flags and still be MFCed. Finally, it is good form to split changes into steps when possible.

In D42762#979649, @michaelo wrote:

In D42762#979550, @michaelo wrote:

In D42762#979469, @karels wrote:

Should this contain the periodic.conf* changes? I would have thought they'd be in the other review only, and now I think they conflict.

No, this is correct. The other one is a MFC'able preprequisite, but this might not be backported, it does not apply anything, but just introduces the flag for daily diff. This applies minimal diff flags to all scripts, effectively. This review cannot be merged into main until the other one isn't merged.

Should this contain the periodic.conf* changes? I would have thought they'd be in the other review only, and now I think they conflict.

This is what I had in mind; let's see what others think.

I did the MFC to stable/14. However, this does not merge to stable/13, which does not use netlink and is otherwise different. It could be done manually, but I won't do it unless there is a reason to do so.

In D42762#978597, @michaelo wrote:

In D42762#978592, @karels wrote:

Sorry, apparently parts were interpreted as markdown, but it was the output of diff and diff -u. My point was that -u is not the default, and is more verbose than the default. WIth the current change, it no longer matters.

Alright so this makes sense to you?

Sorry, apparently parts were interpreted as markdown, but it was the output of diff and diff -u. My point was that -u is not the default, and is more verbose than the default. WIth the current change, it no longer matters.

In D42762#978459, @michaelo wrote:

This one won't be MFC'd. But diff(1) without an option will default to -u as far as I can see. This change is intended for 15 only. The introduction of the flag for all branches.