Looks like this changes behavior by adding -u to the last 3 daily scripts. But I'm not sure why this should be MFCed. Or you could omit daily_diff_flags from /etc/defaults/rc.conf and set defaults in the scripts that currently use -u if the variable hadn't been set.

Seems OK. I wouldn't object to -U 1 either, but for most of these things context is probably unimportant.

There is just no maxdgram limit at all, AFAIU. And we should do
the same unless anybody has good explanation for such a limit.

Ronald, I think you can commit this. You can put "Approved: karels", although that's implied by the reviewers listing.

@imp, any comments? Does this meet your approval?

Add warning for BIOS+GPT.

With the input so far, my inclination is to stay with -D rather than printing the driver name (and unit) by default. I made one small change, which is to print the driver name with -v or -D, so -v is fully verbose.

Print driver name with -v as well as -D. May as well be fully verbose.

In D42721#975428, @freebsd_igalic.co wrote:

I updated comments, but am waiting for more input before making this behavior the default (or something other than -D).

update comments to omit "original name"

In D42721#974773, @freebsd_igalic.co wrote:

I've edited the title summary, to be more explicit about original name vs driver name, so we don't forget about this on commit

In D42721#974723, @zlei wrote:

In D42721#974631, @karels wrote:

There seems to be an unanswered question. Should the driver name be printed

1. With -D only (as now)
2. With -D or -v (so verbose is fully verbose)

Either one should be OK. I would treat -v as an option for debugging purpose.

1. With -v only (I'm not fond of this one)
2. Anytime the driver name is different than the interface name (including the outliers Kristof mentioned)
3. Always (I considered this. and hopefully scripts wouldn't break. but ...)

I'd prefer Always. Just keep it simple. Do not be too smart.

There seems to be an unanswered question. Should the driver name be printed

In D42721#974591, @freebsd_igalic.co wrote:

General questions:

• what's the chance to get this folded into -a/-v?
• what's the chance to get this MFC'd to 14/13/12?

In D42721#974565, @bz wrote:

In D42721#974560, @kp wrote:

I'd prefer describing this as printing the driver name and unit number. This is often the same as the original interface name, but not always.

At the very least epair and if_ovpn deviate from this pattern, and I suspect there are more exceptions. stf does too, I believe, and tun/tap might as well.
I can see this might be useful sometimes, but I'd object to advertising it as something it is emphatically not (that is: the original interface name).

And that is one more time a thing I did not understand 20 years ago and now. We added if_xname and split things out but with renaming we should have kept an if_oname (original name).
That said ifconfig_get_orig_name is really a misleading name that probably still comes out of the 20 year old confusion. Maybe we should fix the underlying issue once and for all as well?

In D42721#974560, @kp wrote:

I'd prefer describing this as printing the driver name and unit number. This is often the same as the original interface name, but not always.

At the very least epair and if_ovpn deviate from this pattern, and I suspect there are more exceptions. stf does too, I believe, and tun/tap might as well.
I can see this might be useful sometimes, but I'd object to advertising it as something it is emphatically not (that is: the original interface name).

In D42721#974556, @bz wrote:

Do you have an example output? Depending on how this ocmes out I wonder if we should just display it along with ifconfig -v (or also with)?

I'm going to push this now, I want it to be live when the release announcement goes out.

Looks good, just one thing to check.

@markj, good with you? Any opinion on whether to have two items for KASAN?

This looks fine to me, but I'm not a vfs expert.

I'm going to push this shortly, as I want it in place when the release announcement comes out. Any feedback can be addressed afterwards.

Replace non-ASCII character.

@imp, do you care if the indents in the continuations are fixed? This file doesn't do them right (where they wrap at all). I guess it shouldn't require retesting though.

LGTM

LGTM

I think it's ready to go too.

I think it looks good as it is now.

Address review comment.

I think it looks good as it is now.

I guess I hadn't done a pass looking for style(9) issues before; better late than never. I see some in original code too; I'd leave those alone, at least in this commit, unless they are intermixed.

Generally looks good. I think I prefer a separate section, so people who know 13.1/13.2 can skip past. Note, I tried to use the [MERGED] notation, and neither I nor carlavilla@ could escape it properly.

About gpart: it is not mentioned in the release notes now, so I'm not sure why we need a caution. Has a gpart procedure been documented for FreeBSD 13, or just the warning? The procedure in the 14.0 notes is quite explicit.

Much improved.

I agree with the overall change.

Looks good, thanks!

In D42496#969749, @mhorne wrote:

One other thing I noticed, "Sponsored by" lines are rendered as regular text; in some previous release notes they used the {{< sponsored "Sponsor" >}} macro. It renders these lines differently, giving a visual hint which IMO makes the information on this page easier to parse.

See for example, the 13.0 release notes: https://www.freebsd.org/releases/13.0R/relnotes/

Ed, feel free. I don't remember if I've done the --author thing before.

Thanks for the mitigations(7) link, I wasn't aware of that one.

Looks good, thanks! I would suggest prepending "the sysctl" to security.... in both places to make it obvious that these are sysctl names. It would probably be good to mention the tunable/sysctl controlling Zenbleed too, as there is no other reference.

I will make one change in the commit: I'm removing the Other Notices section with the "will be removed in 14" message, as it is no longer true.

Mark items Done.

Address Ed's comments

Add kernel crypto items; note arm64 and riscv support for kinst.

Corrections from Graham