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.

In D54037#1234622, @imp wrote:

Why can't we make virtio_p9fs.ko depend on p9fs.ko? That would also cover this case, no? And would confine their visibility to that one module, no? It's how we do pci, etc.

if you confirm Rupesh Pilania <rupeshpilania@gmail.com> as the git commit author I'll push this, thanks!

Looks like:

Add notes from wulf@

LGTM

FYI I didn't look closely at the ones after XHCI_DCST

It is better to provide an explicit list of symbols than just EXPORT_SYMS=YESunless we are sure that all symbols should be exported. But, this enough to preserve the status quo at least.

If it renders like https://www.freebsd.org/releases/13.0R/relnotes/ and not https://www.freebsd.org/releases/14.0R/relnotes/ looks good to me

@mav reported a regression; at least one issue is linux.ko depends on kern_kmq_open as of 97add684f5306ebf93be238a0340597ba1898d0e. Now fixed by eb90470f5f2a0e5c820c47be329423f5c60ca247 and a897492770735d4e5a55cbc06a02e267ca41f5b8. @cy reported a regression when agp is loaded as a module, fixed by a87c1e2dd8fc997d6ee603c252c543afe8a4d2a4.

The issue I have with "maintenance" is that then 14.x releases are production releases that get maintenance updates and 13.x releases are maintenance releases that are suitable for use in production.

All the variables in here would benefit from documentation but we can start with these

Would be good to indicate in the commit message how far back in gcc and clang __builtin_align_up is supported.

Thanks. Thinking more about it, it does seem sensible to execute all of the teardown steps for this module before doing the dependencies.

LGTM. I do wonder if there's a reason the steps in the kld_unload EVENTHANDLER aren't (shouldn't be) handled in the same place as sysctls / sysuninits?

Writing seems fairly straightforward but indeed would be nice to have centralized infrastructure for it.

@wulf can we add a sentence or two about any user-facing impact, config changes, etc.? For most people it will be a no-op.

Will add to the commit message:

This isn't used by modern cards, but is needed for i915kms to load
on a system that has agp as a module not compiled into the kernel.