but don't provide an example

Just reverted instead, "may be" removed in 15.0 is good enough.

(for direct commit to stable/14)

This should be run through the test suite, in case tests are relying on this behaviour.

OK with me. I'd suggest we don't MFC though.

Oh it looks like / needs to be escaped in the [] expression, so [.-\/]. I tried that expression locally and it looked OK but double check

Oh yeah, of course -- I missed the . if !defined(${_V}) || empty(${_V}). So then the question is do we want to take the branch from Cirrus? I.e., is FreeBSD-16.0-CURRENT-amd64 desired, or FreeBSD-16.0-pull_1234-amd64?

This seems a bit strange - BRANCH should be coming out of newvers.sh and be something like BRANCH="CURRENT" (unless BRANCH_OVERRIDE is set). How is pull/XXXX making its way in?

No objection, seems fine. This will be the first use I believe?

Let's give it a shot!

Fine with me

Addressed by 2780a26b6a306

CAVEATS is a standard section at the bottom.

Move caveat to end of description, and remove comment about only being a kernel module

Can be compiled into kernel

add to sys/conf/files

It's not guaranteed to be true in general, but this is just intended prevent foot-shooting in the default/common case, where DESTDIR and INSTKERNNAME are not set and default to / and kernel, respectively.

It is used only as an opaque pointer in LinuxKPI code. If we want to ensure the native struct is not exposed in LinuxKPI we'll just end up with a bunch of casts. Your concern is the same thing I was getting at with the cross-threaded comment above -- right now it is fine, but is a potential future issue.

ping

So the linuxkpi_skb_memlimit is used to give contiguous > PAGE_SIZE allocations and to limit allocations to 32 or 36 bit addresses, so what do we do about the latter? How does rtw88 on Linux handle this?

This is quite different from our version.

I'm not sure about the option name and descriptions; WITH_LLVM_STATIC suggests that these will be statically linked binaries. And, Build LLVM libraries (libllvm, libclang, liblldb) as internal static libraries. isn't a great user-facing description because it's just an artifact of the build process and the user doesn't see the result. Maybe "Link LLVM libraries (libllvm, libclang, liblldb) directly into each of the binaries that use them."? What do you think about calling it WITH_LLVM_LIBRARIES?

I think in 16.0 we won't be shipping distsets at all, so this menu will go away.

Or perhaps we should continue to use "traditional" for a potential MFC before 15.1.